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:
- 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) - 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
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
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)
and here after the terminal screenshot of the example DHCP code from SDK running from 0x10100 (not working, it hang in the checking state)
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?
