SDK_2_.x_LPC54008J512 examples freertos/lwip problem/bug

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SDK_2_.x_LPC54008J512 examples freertos/lwip problem/bug

1,601 Views
A_M
Contributor III

Hello I have a issues with the
SDK_2_.x_LPC54008J512 2.13 MCUXpresso IDE v11.7.1_9221
SDK_2_.x_LPC54008J512 12.14 MCUXpresso IDE v11.8.0_1165
The testboard is the lpcxpresso54628 eval brd rev e.
Some LWIP examples doesn’t work.
lpcxpresso54628_lwip_ping_freertos
lpcxpresso54628_lwip_httpsrv_freertos.
They crash when reach the breakpoint in stack_init(
I only import the examples buld and start the debugibg. I didn’t make any change.
See pictures.

Screenshot 2023-08-04 164458.png

Screenshot 2023-08-04 164601.png

  

It seems that the linker link some functions to external ram. o_0 Add: 0xA5A5A5A4.

The example lpcxpresso54628_lwip_dhcp_freertos doesn’t crash on breakpoint in stack_init(.

Quick test with MCUXpresso IDE v11.5.1_7266 and SDK 2.7.0 shows that the lpcxpresso54628_lwip_ping_freertos there works fine.

Is this a bug or a wrong setting?
I would be grateful for a solution.

Tags (3)
0 Kudos
Reply
6 Replies

1,405 Views
A_M
Contributor III

Hello Raul,

Like NXP recommend I’ve made the update from the SDK. I’ve made an update of my project from V2.7 to V2.13 (fsl stuff, phy and lwip) and now its hangs in the enet software reset function. DMA mode register Software reset Bit stays ‘1’.
The v2.7 was working out of the box. There was no need to go deep in it. Now I need to understand the initialization to fix it. That’s why the break point is there.


Even when the Break point is set in stack_init(picture). RTOS execute in external ram! But there is no init for external RAM PINs or a call of BOARD_InitSDRAM(void); I made a test and comment BOARD_InitSDRAM out…

So where is the init for external ram if the use of external ram is not a bug? Why its paced in the external ram? lpc54xxx cann not set a break point there but rtos is executed there. So, for debugging is almost useless…

0 Kudos
Reply

1,358 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @A_M,

First of all, we apologize for our delay. We are still checking this issue.

At the meantime, could you please try with another USB port on the PC, use a powered USB hub, or preferably use an external power supply to provide the power instead?

Finally, why are you mentioning that the stack_init() function is in external RAM? Could you please build the project and check the Image Info? You might see where the code and specific functions are place in memory at Memory Contents.

RaulRomero_0-1692294189889.png

 [MCUXpresso IDE's Image Info -> Memory Contents]

Best regards, Raul.

0 Kudos
Reply

1,301 Views
A_M
Contributor III

Hello Raul,

That the stack_init is executed in external ram was a wrong expression from my side.

The image info shows that there is nothing placed in external ram.

A_M_0-1692948691068.png

But there is something wrong, somewhere a problem. Please correct me, but the MCUxpresso shouldn’t show an address at 0xa5a5a5a4 because there is nothing.

We try the example lpcxpresso54628_lwip_ping_freertos on two computers and different usb ports. The behavior/errors was the same.

Best regards, Alex

0 Kudos
Reply

1,236 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @A_M,

Sorry for the delay. Could you please do the following changes to the project?

  • Change #define configENABLE_BACKWARD_COMPATIBILITY to 1 in FreeRTOSConfig.h
  • Right click on your project, go to Properties -> C/C++ Build -> Settings -> MCU C Compiler -> Optimization. There please change the Optimization Level to None (-O0).

RaulRomero_0-1693846819266.png[Properties- > C/C++ Build -> Settings -> Optimization]

We made it work in our side with an LPCXpresso546xx Rev D and the SDK_2.14_LPCXpresso54628.

Once again, we apologize for the delay. Let us know if the setting mentioned work on your side.

Best regards, Raul.

0 Kudos
Reply

1,162 Views
A_M
Contributor III

Hello Raul,

it was enough to set the debug setting to None (-O0).
It worked regardless of how configENABLE_BACKWARD_COMPATIBILITY 0/1 was set.

It seems to be a compiler problem.

Best regards, Alex.

1,567 Views
RaRo
NXP TechSupport
NXP TechSupport

Hello @A_M,

There are a couple of differences between the SDK v2.7 and v2.13-2.14 of the examples. In newer versions they are using a different ethernet configuration by using specific code for the PHY LAN8720A. Also, the v2.14 examples use FreeRTOS Kernel V10.4.3, while the v2.7 ones use the FreeRTOS Kernel V10.2.0.

If it is completely necessary to use the breakpoint there, could be useful to use v2.7 example. Nonetheless, there is not recommended to work with older SDK versions. Could you please give us more details about the reason or usage of the breakpoint there?

Best regards, Raul.

0 Kudos
Reply