LPC54608 problem with LwIP and address flash offset

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

LPC54608 problem with LwIP and address flash offset

1,246 Views
cybaluke
Contributor III

Hi,
I'm working with LPC54608,LwIP and MCUXpresso IDE v11.7.0 SDK2_13.
In my project I need a 2-steps bootload, in the first step the bootloader located @0x000 flash address doesn't use lwip stack, after some initials checks it jumps to the main app placed @0x010100 flash address, in the Main App I configure and use lwip stack and etc...
I have a strange problem with the lwip code in the MainApp:
if the flash code of the main App runs @0x00000 address the lwip code works correctly, if the flash address has an offset, i.e the project of Main App is located @ flash address 0x10100 the lwip doesn't run correctly.
I'm missing something or should I set some particular options when i relocate the lwip and my main app code to another flash address (for the 2-steps bootloader)?

Just to test and replicate this problem, I have create and attached 2 projects for the EVB-OM13092 that replicate exacly my situation:

  1. lpcxpresso54608_bootloader:
    this project emulate my small bootloader @0x000 flash address, it simply print a string to the semi-host console and jumps to the MainApp code @0x10100 (just flash this code first to the OM13092 ev-board memory)
  2. lpcxpresso54608_lwip_dhcp_bm_flashoffset:
    this is my MainApp @0x10100 flash address that replicate the problem. As you can see this is exactly the baremetal example lpcxpresso54608_lwip_dhcp_bm from the sdk, as expected if this code runs @0x00flash addres it works well, but when it is compiled and flashed @0x10100 via the right MCUSettings dialog and after the correct jump from the bootloader, it doesn't run because it start the dhcp procedure but it doesn't seems to receive any dhcp answer packets.

In the picture the offset setting for the Main App example @ 0x10100 flash address location

Immagine 2023-03-07 102525.jpg


I'm missing something for lwip settings when I relocate its whole code to another flash address different from 0x0000?
Have you any suggestions?

Thanks

Labels (1)
Tags (2)
0 Kudos
Reply
5 Replies

1,142 Views
cybaluke
Contributor III

Hello, no other suggestions about this topic?

Any idea about the problem I find when I relocate lwip library on flash memory address different from 0x00 with MCUXpresso??

0 Kudos
Reply

1,229 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi,

I have checked your bootloader project and lwip_dhcp_bm_flash_offset project, the bootloader project just implements the jumping function to application code, which can not receive code from uart and write to on-chip flash. The lwip_dhcp_bm_flash_offset project is just a application project located at 0x1_0100 address.

I suppose the MCUXpresso implements mass erasing, when you download the second project, the first one will be erased.

I suppose that you can use MCUXpresso tools to download the bootloader project to flash located at 0x0000. You can convert the lwip_dhcp_bm_flash_offset project as a *.bin file, use another tools such as J-Flash to write the .bin file to 0x1_0100, then press Reset and check if your application can run or not.

Pls download the AN12384 from the link:

https://www.nxp.com.cn/docs/en/application-note/AN12384.pdf

Hope it can help you

BR

XiangJun Rong

 

0 Kudos
Reply

1,220 Views
cybaluke
Contributor III

Hi XiangJun Rong, thanks for your replay and for the app note link,

I have checked your bootloader project and lwip_dhcp_bm_flash_offset project, the bootloader project just implements the jumping function to application code

That's right I've isolated the simplest function just to jump to the application project located #0x10100. This is not the problem, as I can see the jumper works well, I just flash it with MCUxpresso first @0x0000 once time and after I can work and debug only on the application code @0x10100 (see below)

I suppose the MCUXpresso implements mass erasing, when you download the second project, the first one will be erased.

That's wrong, as I can see MCUxpresso doesn't explicity mass erase all the flash when I debug the second project. When I debug with MCUxpresso the second application project located at address 0x10100 the debugger download only the flash code from 0x10100 but it doesn't erase the above bootloader/jumper previously flashed @0x0... This works correctly and I just can debug only the second application project because at the reset MCUxpresso first lets run the bootloader @0x0 which jumps @0x10100 and then it runs (and debug) the application project @0x10100.

... BUT... My problem is not on this boot process, I already use it in many other projects and it works right, in my application project I already can use it with most of the LPC546xx peripherals (CAN, UART, SPI, SPIFI, etc) and they all work well.

My problem seems to be only on lwip stack it seems to not work correctly when I relocate its flash code @0x10100 address (or a different address from 0x00)

This is the reason because I have replicate the problem with a standard SDK dhcp baremetal example running on a standard EVB-OM13092 board.

Here after the terminal screenshot of the example DHCP code from SDK running from 0x00 (good working)

Immagine 2023-03-08 091941.jpg

and here after the terminal screenshot of the example DHCP code from SDK running from 0x10100 (not working, it hang in the checking state)

Immagine 2023-03-08 093743.jpg

Here after the terminal reports when I enable the DHCP and UDP lwip debug options in lwipots.h

 

[MCUXpresso Semihosting Telnet console for 'lpcxpresso54608_lwip_dhcp_bm_flashoffset LinkServer Debug' started on port 50496 @ 127.0.0.1]
************************************************
Mini-Bootloader jump to MainApp
************************************************
Initializing PHY...
dhcp_start(netif=0x20027fb4) en0
dhcp_start(): mallocing new DHCP client
dhcp_start(): allocated dhcp
dhcp_start(): starting DHCP configuration

udp_bind(ipaddr = 0.0.0.0, port = 68)
udp_bind: bound to 0.0.0.0, port 68)
udp_connect: connected to 0.0.0.0, port 67)

dhcp_discover()
transaction id xid(abcd0001)
dhcp_discover: making request

dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, WIP_IANA_PORT_DHCP_SERVER)

udp_send: added header in given pbuf 0x200001a0
udp_send: sending datagram of length 316
udp_send: UDP packet length 316
udp_send: UDP checksum 0x724f
udp_send: ip_output_if (,,,,0x11,)

dhcp_discover: deleting()ing
Initializing PHY...
dhcp_start(netif=0x20027e84) en0
dhcp_start(): mallocing new DHCP client
dhcp_start(): allocated dhcp
dhcp_start(): starting DHCP configuration

udp_bind(ipaddr = 0.0.0.0, port = 68)
udp_bind: bound to 0.0.0.0, port 68)
udp_connect: connected to 0.0.0.0, port 67)

dhcp_discover()
transaction id xid(abcd0001)

dhcp_discover: making request
dhcp_discover: sendto(DISCOVER, IP_ADDR_BROADCAST, WIP_IANA_PORT_DHCP_SERVER)

udp_send: added header in given pbuf 0x200001a0
udp_send: sending datagram of length 316
udp_send: UDP packet length 316
udp_send: UDP checksum 0x724f
udp_send: ip_output_if (,,,,0x11,)
dhcp_discover: deleting()ing
dhcp_discover: SELECTING
dhcp_discover(): set request timeout 2000 msecs
************************************************
 DHCP example
************************************************
udp_input: received datagram of length 310
UDP header:
+-------------------------------+
|        67     |        68     | (src port, dest port)
+-------------------------------+
|       310     |     0xa496    | (len, chksum)
+-------------------------------+

udp (192.168.1.14, 68) <-- (192.168.1.1, 67)
pcb (0.0.0.0, 68) <-- (0.0.0.0, 67)
udp_input: calculating checksum
dhcp_recv(pbuf = 0x20009d1c) from DHCP server 192.168.1.1 port 67
pbuf->len = 302
pbuf->tot_len = 302
skipping option 2 in options
skipping option 6 in options
skipping option 12 in options
searching DHCP_OPTION_MESSAGE_TYPE

DHCP_OFFER received in DHCP_STATE_SELECTING state
dhcp_handle_offer(netif=0x20027e84) en0
dhcp_handle_offer(): server 0x0101a8c0
dhcp_handle_offer(): offer for 0x0e01a8c0
dhcp_select(netif=0x20027e84) en0

transaction id xid(abcd0001)
udp_send: added header in given pbuf 0x20000324
udp_send: sending datagram of length 316
udp_send: UDP packet length 316
udp_send: UDP checksum 0x86e4
udp_send: ip_output_if (,,,,0x11,)

dhcp_select: REQUESTING
dhcp_select(): set request timeout 2000 msecs
udp_input: received datagram of length 310
UDP header:
+-------------------------------+
|        67     |        68     | (src port, dest port)
+-------------------------------+
|       310     |     0x2d8f    | (len, chksum)
+-------------------------------+
udp (192.168.1.14, 68) <-- (192.168.1.1, 67)
pcb (0.0.0.0, 68) <-- (0.0.0.0, 67)
udp_input: calculating checksum
dhcp_recv(pbuf = 0x20009d5c) from DHCP server 192.168.1.1 port 67
pbuf->len = 302
pbuf->tot_len = 302

skipping option 2 in options
skipping option 6 in options
skipping option 12 in options
searching DHCP_OPTION_MESSAGE_TYPE
udp_input: received datagram of length 310
UDP header:
+-------------------------------+
|        67     |        68     | (src port, dest port)
+-------------------------------+
|       310     |     0x2a8f    | (len, chksum)
+-------------------------------+

udp (192.168.1.14, 68) <-- (192.168.1.1, 67)
pcb (0.0.0.0, 68) <-- (0.0.0.0, 67)
udp_input: calculating checksum
dhcp_recv(pbuf = 0x20009d7c) from DHCP server 192.168.1.1 port 67
pbuf->len = 302
pbuf->tot_len = 302
skipping option 2 in options
skipping option 6 in options
skipping option 12 in options
searching DHCP_OPTION_MESSAGE_TYPE

DHCP_ACK received
dhcp_check(netif=0x20027e84) en
dhcp_check(): set request timeout 500 msecs
 
DHCP state       : CHECKING

 

After this it can't complete the CHECKING state, so it can't BOUND and complete the dhcp process.

Is there something wrong on relocating the SDK dhcp example (and lwip library) at flash address different from 0x00? I'm missing some memory definitions for lwip? Are there some structures in lwip stack that should be manually relocated in memory or flash?

Any suggestions about it?

 

0 Kudos
Reply

1,211 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi,

I suggest you develop an application example for example LED toggling, then use the bootloader to download. In this way, you can identify if the bootloading is wrong or the application code itself is wrong.

BR

XiangJun Rong

0 Kudos
Reply

1,208 Views
cybaluke
Contributor III

Hi, I've already developed many example to confirm that the bootloader described works well, LED toggling or other more complex examples from sdk or others applications of mine work all well... I think the problem is not in the bootloader...and also the MCUxpresso flash offset-address setting works well too.

I've found the first problem only with lwip stack library from sdk, so I'm asking if there is any trick to relocate lwip stack that I'm missing, i.e. any absolute address memory allocation of data structures in lwip that can't be relocated in different memory spaces or that should be placed in memory with specialized functions in MCUxpresso...

Any idea on these LWIP problems?

0 Kudos
Reply