lpcxpresso 1769 embedded artists base board

This is the link to the sample application of a speaker test tone the base board with the code for the LM4811

www.embeddedartists.com/.../lpc17xx_xpr_bb_120314.zip

www.filefactory.com/.../lpc17xx_xpr_bb_120314_1_zip

This is the link to the sample application of a speaker test tone the base board with the code for the LM4811

www.embeddedartists.com/.../lpc17xx_xpr_bb_120314.zip

www.filefactory.com/.../lpc17xx_xpr_bb_120314_1_zip

I still can not get any audio what so ever hope you can help.

> but I don't know how to get audio out of the board, because it is set up for PWM

This USBAudio example puts sound over DAC output to P0.26
I'm not sure, what connects to this pin on the Embedded Artists base board, because I don't have the base board. Above EA user's guide gives just vague information.

Tsuneo

I was just giving schematics, trying to work out from that, I could end up just soldering a wire to P0.26 pin at this rate, if I can't work out this board.

by154w.bay154.mail.live.com/.../

I was told this

>ave a look in file usbdmain.c, row: 132.
>This line does not seem correct:
>LPC_ADC->ADCR = 0x00200E04; /* ADC: 10-bit AIN2 @ 4MHz */
>It should be like this instead, I think:
>LPC_ADC->ADCR = 0x00200E01; /* ADC: 10-bit AIN0 @ 4MHz */

Also, test to hardcode the volume to some suitable value.

I think they were wrong on this one tho, I think it is correct

>To get audio out you do not have to do anything. The signal GPIO_14 that carries the audio >signal is the >same as on the mcb1700 board. It is also an analog output from the DAC so the PWM >functionality does >not have to be used. Just pure audio samples.
>Have J31 and J32 inserted.
>Have jumpers in J33 not inserted. Later on you can insert these jumpers and control the volume >via this.
>I suspect the USBaudio code control the volume via scaling of the samples right now. You have >to change >which analog input that controls this. The mcb1700 board has the trimming pot >connected to ADIN0.2, >while on the LPCXpresso base board it is on ADIN0.0.

They say I could not be getting audio because of the trimming pot Pot val part of the code Get Potenciometer Value

void get_potval (void) {
  uint32_t val;

  LPC_ADC->ADCR |= 0x01000000;              /* Start A/D Conversion */
  do {
    val = LPC_ADC->ADGDR;                   /* Read A/D Data Register */
  } while ((val & 0x80000000) == 0);        /* Wait for end of A/D Conversion */
  LPC_ADC->ADCR &= ~0x01000000;             /* Stop A/D Conversion */
  PotVal = ((val >> 8) & 0xF8) +            /* Extract Potenciometer Value */
           ((val >> 7) & 0x08);
}

Not sure what to do or how to change it at the moment

If you look at board and schematics P0.25 is connected to one of
Rotary Switch connectors QA J54 jumpers

TMS / PIO1_0 / AD1 / CT32B1_CAP0 P0.24 ain1 tms Qa

I can't understand why that is effecting the voulume and causing it to be muted or 0

It looks like I need to mod the Get Potenciometer code somehow does anybody know how to change it.

I took it off the base board and put in on a bread board, still no audio so I guess it must be another bug somewhere.

Did you managed to get audio out of your lpcxpresso yet if so please post the uvision project for me, please remember to include all files lpc17xx.h and system files which I see people always leaving out.

The files that reside in the common folder people always leave them out

Note that the license terms may not even allow any lpc17xx.h file to be posted.

For commercial projects, a customer may expect to receive a full delivery containing everything required to recreate a project. But even in that situation, the customer will have to miss something unless an open-source compiler is used.

Do you have any idea of this strange bug that is plaguing the lpcxpresso1769 I don't have hardware analyser do you have one maybe you could check why still not audio is coming out of the board from the code posted on nxp's website. which happens to be your code.

I'm a developer. If nothing else, I would be able to write a small piece of code that toggles the suspected pin at 1kHz to check if I do get audio. Then take the debugging from there depending on the outcome of the test.

Don't you have access to an oscilloscope or something, to figure out if you have an issue on the software side or with the hardware outside the processor?

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.