lpcxpresso 1769 embedded artists base board

It is a bug in the code again, which I can not detect without the hardware analyser. I guess I will just have to wait for chinzei.

Or maybe chinzei, will post usbaudio code that he has got working on the lpc1769, for some reason even newer code will not work, well I have flash bin files onto the lpc1769 created with uvision and they will not work. The only one that works at the moment is the one that has bugs in the usbcore.c with no audio.

But with, or without, his help, you should be able to figure out if the issue is with the USB code handing over audio data to for playback, or if the issue is with the generation of the audio or if it is with the hardware picking up the audio hand delivering it to an audio jack.

You can even add some code lines that on press of a button captures the next 100 audio samples the USB code thinks it receives and stores them in a buffer - then they can be dumped on a serial port to verify if you do get real samples.

Exactly what have you done to subdivide this issue into smaller pieces and figure out where in the chain it fails?

The thing is, is that the same code works on the lpc1768 but it will not work on the lpc1769, how I am supposed to be able to fix problems like this.

... how I am supposed to be able to fix problems like this.

It might be worth you considering a different career.

The NXP LPC1769 site ( " href= "http://ics.nxp.com/support/documents/microcontrollers/zip/mcb1700.code.bundle.lpc17xx.keil.zip"> ics.nxp.com/.../mcb1700.code.bundle.lpc17xx.keil.zip

2) MCB1700 Sample Code Bundle for LPC1769 Peripherals using LPCXpresso, V2.00 (Jan 10, 2011)
ics.nxp.com/.../mcb1700.code.bundle.lpc1769.lpcxpresso.zip

I believe the first one is provided by Keil, because the USBAudio example is same as the example distributed with Keil MDK-ARM. The second one, on your first post, seems to be ported from Keil example for LPCXpresso IDE (ie. GCC) (by NXP LPCXpresso team?)

I compared the source files of both bundles for USBAudio.
Most of changes are fine. They are based on the difference of packed structure declaration.
Just uint8_t --> uint32_t change in USB_ReqSetConfiguration() and USB_ReqSetInterface() (usbcore.c), as pointed out on above post, has introduced bug.



Another problem is the mapping to USB DMA RAM
In this part of the code, these arrays are mapped to the DMA RAM, starting from 0x2007 c000
But "#pragma arm section" is good just for Keil. GCC will ignore it.

usbhw.c

#pragma arm section zidata = "USB_RAM"
uint32_t UDCA[USB_EP_NUM];                     /* UDCA in USB RAM */

uint32_t DD_NISO_Mem[4*DD_NISO_CNT];           /* Non-Iso DMA Descriptor Memory */
uint32_t DD_ISO_Mem [5*DD_ISO_CNT];            /* Iso DMA Descriptor Memory */
#pragma arm section zidata

For GCC, above code is ported as,

uint32_t UDCA[USB_EP_NUM] __attribute__ ((section ("USB_RAM")));            /* UDCA in USB RAM */
uint32_t DD_NISO_Mem[4*DD_NISO_CNT] __attribute__ ((section ("USB_RAM")));  /* Non-Iso DMA Descriptor Memory */
uint32_t DD_ISO_Mem [5*DD_ISO_CNT] __attribute__ ((section ("USB_RAM")));   /* Iso DMA Descriptor Memory */

Also, you have to declare USB_RAM section (ORIGIN = 0x2007c000) in \USBAudio\Debug\USBAudio_Debug_mem.ld
In this linker script, RamAHB32 occupies this section. Move RamAHB32 to upper address and make room for USB_RAM. The LENGTH of USB_RAM section is, err.., count up above arrays ;-)

Tsuneo

The thing is that most code do not work initially. So how am a poor developer supposted to be able to fix problems like that?

The way the society have found to move forward is to try to attempt debugging broken code. It is a significant part of a developers life to compare what happens with what was expected to happen, and then try to deduce something from that - or potentially break the problem down into smaller problems until the error(s) are identified and taken care of.

The interesting thing here is that new developers write code that they have already written many times before. So most times, they are breaking new ground. But they still have to perform their debugging or they would be stuck. There can't automagically exist someone who do know more and can step in and do the debugging.

I just had to use a .axf file to flash the lpcxpresso 1769 instead of a bin file, I built the .axf with the sample bundle with .102 at the end LPC17xxSampleSoftware.102