Software runs but some peripherals doesn't when target started without JTAG/SWD.

[lpcware]

Content originally posted in LPCWare by rody on Wed Sep 09 01:23:58 MST 2015
The software runs without problems when JTAG/SWD. It continues to run without problems when the JTAG/SWD is disconnected, by disconnecting the JTAG/SWD connector. It has problems when the JTAG/SWD is disconnected and the target is powered off and on.

So far i understand is sets lpcexpresso the target to SWD by default when starting with debugging. Apparently when this is done the software runs and if not it runs with problems. 

The software uses Freertos, lwip (1.4.1) and lpcopen. Heap_5 is used and a HeapRegions are mapped in AHB and standard memory. (2 regions).
The standard sysinit.c and startup files are used.
The software has two parts:
- lpc_chip_175x_6c (lib)
- application

As far I can see for now, the ADC on [u]DMA [/u] and ethernet is not working. Init problem with AHB memory? I tried several setup's...

The ADC is in burst mode and generates an interrupt if ADC7 is sampled. Then a DMA transfer is started to copy the DAC data to an array in AHB memory. The DMA interrupt  is never executed. To debug this I write a '#' to the UART.

The PBUF's etc used for ethernet is also placed in AHB  memory.

The software does not use semihosting, the libraries are not linked. We use Redlib(nohost), DEBUGOUT macro's are not used. We use our own printf what formats the data to a ringbuffer. This ringbuffer is send to the uart. The uart  runs on interrupt.

The JTAG hardware pins are pulled up and down accordingly to: https://www.lpcware.com/content/faq/lpcxpresso/debug-design

[lpcware]

Content originally posted in LPCWare by rody on Tue Mar 15 00:27:49 MST 2016
Indeed. I did the same (sorry forgot to post).

Just move the descriptor table and adc buffer  to AHB.

If you use the heap for LWIP, you [u]must [/u]map it completely in AHB. Ethernet also requires AHB mem (DMA), if not your system will not be stable.
Better is to use the PBUF's and make the mapping static. This way you can map the heap used by freertos in standard RAM en partly in AHB (heap_5).

[lpcware]

Content originally posted in LPCWare by vtube on Wed Mar 09 06:02:14 MST 2016
Solution: move emac descriptors and buffers on RAM2.
I had to canghe lwip memory management tfrom redlib malloc to internal malloc.

Andrea

[lpcware]

Content originally posted in LPCWare by vtube on Tue Mar 08 05:42:37 MST 2016
I'm having the same issue.
LPC179 LPCXpresso (old revision); lpcopen 2.10, code based on tcpecho sample.

When code is executed during debug session, everything goes well.
When code is in free running, tcp communication hangs.

Printing lwip stats and debug messages over uart3, with a pc pinging to the board, I guess there are many dropped packets:

LINK
xmit: 10
recv: 10
fw: 0
drop: 37
chkerr: 37
lenerr: 37
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0

IP
xmit: 6
recv: 6
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0

ICMP
xmit: 6
recv: 6
fw: 0
drop: 0
chkerr: 0
lenerr: 0
memerr: 0
rterr: 0
proterr: 0
opterr: 0
err: 0
cachehit: 0
lpc_rxqueue_pbuf: pbuf packet queued: 0x10005dd4 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
lpc_rxqueue_pbuf: pbuf packet queued: 0x10006434 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
lpc_rxqueue_pbuf: pbuf packet queued: 0x100044e4 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)
lpc_rxqueue_pbuf: pbuf packet queued: 0x10003ec8 (free desc=0)
lpc_low_level_input: Packet dropped with errors (0xffffffff)


Some time some packet survives, but nearly all are discarded. So I think there is something related to external MAC configuration.

Any hint?

Thanks!

Andrea

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Sep 11 08:31:10 MST 2015
Sorry I'm out of ideas. The only other thing I can think of is perhaps you have some form of cross talk or shorting on your board between the MCU to debug connector wires and the IO.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by rody on Fri Sep 11 03:49:10 MST 2015
Another test:

Like above. But instead of the while(!start) I now wait for a button pressed.

- debugger not connected, but ready with  attach only = true.
- start target by applying power
- connect the debugger when waiting for button
- and disconnect it again after 2 seconds, so nothing is really done with it.
- press the button to continue
- and... it works.

Why is the debugger needed? What does it do when you connect connected it? I can only think of two things
- some init is done by the debugger
- setting the hardware pins to some levels? (I pulled up TRST, TDI, TDO and TMS, and pull down TCK, all with 10k). RTCLK is not used and is not connected.

[lpcware]

Content originally posted in LPCWare by rody on Fri Sep 11 00:21:11 MST 2015
I changed the code:

There is one task what inits the ADC/DMA when started and in the while(1) loop every second a '.' is send to the uart (blocking). A '#"is send on the DMA interrupt.

Before init a while(!start) loop is added. The debugger is needed break the loop so the code continues.

- I program the target and run it on the debugger with attach only false -> the runs fine.
- Then a disconnect the debugger en power cycle the target. The code is running until the while(!start) loop.
- Now the debugger is connected, with attach only true.
- When I now pause the debugger, it hangs in the while(!start) loop. With the debugger I set start to 1, breaking the loop and run the code again
- In the msDelay(10000) remove the debugger connector from the target,

So basically only the while(!start) and a part of the msDelay(10000) is executed using the debugger, no real code what maters.

Result: The code is working!
It seems that only attaching and executing some code with the debugger is enough to let it work. What does the debugger do in SWD mode? Is there some kind of init?
And what has Freertos to do with it? I tested before in previous code that I works fine when Freertos is not running (vTaskStartScheduler() not executed).

//--

static xTaskHandle xTestTaskHandle = NULL;/* Holds the handle of the Debug task. */

static void TestTask(void *pvParameters)
{
volatile int start=0;

Chip_UART_SendStringBlocking(LPC_UART0, "\r\nWait... \r\n");
while(!start);

msDelay(10000);

Board_ADC_Init();


Chip_UART_SendStringBlocking(LPC_UART0, " After ");

while (1)
{
Chip_UART_SendStringBlocking(LPC_UART0, ".");
msDelay(1000);
}
}

static void Board_TestStartTask(void)
{
xTaskCreate(TestTask, "TTest       ",
configMINIMAL_STACK_SIZE,
NULL,
2,
&xTestTaskHandle);
}

//--

/**
* @briefmain routine
* @returnNothing, function should not exit
*/
int main(void)
{
SystemCoreClockUpdate();
        Board_Init();
        Board_DebugUart_Init();
Board_TestStartTask();

vTaskStartScheduler();

while(1);

/* Should never arrive here */
return 1;
}

//--

[lpcware]

Content originally posted in LPCWare by rody on Thu Sep 10 23:18:17 MST 2015
I tried the attach only:
- first I run the project with the debugger attached, program is programmed and running ok with the debugger attached
- then I removed the debugger connector and restarted the target.
- now it does not work.
- I added I simple task what send an '.' every second, this is working, but the ADC/DMA does not!
- then I connected the debugger and set the "attach only" option, now I can break the code to find out what it is doing, nothing strange, no assert

My project now does not have ethernet, so I focus now on the ADC/DMA.
Ethernet is running without problems when debugger is attached in the original project.

I'm using the LPC1768, running the crystal, clock is set to 96MHz.
I'm not using a eval.board. It is on our target.

Does it help if I port the Lpcxpresso eval.board (LPCXpresso LPC1769 Rev C) and post the project? Than can  see what I have done exactly and reproduce the problem?

Edit:
Is it a coincidence that only the AHB peripherals (DMA and Ethernet) are not working when the JTAG is not attached?!

Edit:
I switched to FreeRTOS 8.2.2 using the latest port files, same problem. I do not think FreeRTOS (heap stack, task) is really the problem, I think I'm missing some init for AHB peripherals/matrix... But why is it running when freertos is not started and why not if started, I really do not know.

Edit:
The debugger I use is not JTAG but SWD, I using the | (LPCXpresso LPC1769 Rev C".

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Sep 10 01:53:18 MST 2015
Your description sounds like either the FreeRTOS heap or stack are "going wrong" - though I can't see why that would only happen when you are running from reset rather than starting a debug session.

Have you tried making an "attach only" debug connection - this might allow you to determine where your application code has ended up...

https://www.lpcware.com/content/faq/lpcxpresso/debugging-running-system

And if you then end up in say, a hard fault, then this might help to determine why...

https://www.lpcware.com/content/faq/lpcxpresso/debugging-running-system

One other thing to note is that there is the occasional report of ethernet startup issues when debug tools are/aren't connected. For example:

http://www.support.code-red-tech.com/CodeRedWiki/RDB4078Docs/UserManual#Ethernet
https://www.lpcware.com/content/forum/ethernet-failed-anyone-faced-this
https://www.lpcware.com/content/forum/distance-between-mac-and-phy

Maybe you are encountering something similar?

If none of this helps, please confirm exactly what you see when you try and attach only debug connection and also tell us exactly which MCU you are using, what board it is, and to also post the linker map file generated by building your project.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by rody on Thu Sep 10 00:29:10 MST 2015
I stripped the code even more. Only thing it does now is servicing the ADC using DMA and print a '#' (Chip_UART_SendStringBlocking) on the dma interrupt, nothing is done with the sampes. I mapped everything to local memory. I removed board_retarget.h and I'm using the default linker script.

Freertos is in my project, using heap_5:
If I do not call "vTaskStartScheduler()" the '#'is received. If I do call  vTaskStartScheduler()" is isn't.
There are application no tasks.

HeapRegion_t xHeapRegions[] =
{
{ ( uint8_t * ) &xHeapLocalMem[0], HEAP_LOCALMEM_SIZE },//Heap block in standard mem
{ NULL, 0 }
};

int main(void)
{
SystemCoreClockUpdate();
vPortDefineHeapRegions( xHeapRegions );

/* Board_SystemInitDefault is called before main in startup */
Board_Init();

        Board_DebugUart_Init();
Chip_UART_SendStringBlocking(LPC_UART0, "\r\n\nStarting...\r\n\n");
Board_ADC_Init();

-->vTaskStartScheduler();

while(1);

/* Should never arrive here */
return 1;
}

[lpcware]

Content originally posted in LPCWare by rody on Wed Sep 09 03:26:20 MST 2015
I tried building a release, debugger set to None. Programmed the hex using Flashmagic. Same result.

I stripped to code to the minimum, only using ADC on DMA and the printf to the uart. No ethernet, no lwip, etc. Same result.

Even when I map the heap and ADCbuffer to standard memory, (AHB is not used), it does not work.

When debugger connected I get the # periodically (DMA interrupt), but without the debugger at startup, nothing. The startup print is printed, but no #