I’m trying to connect an mbed NXP LPC1768 in ethernet with FreeRTOS+TCP. I’m using MCUXpresso 11.1.2, but I did the same tests with MCUXpresso 10.3.0 and 10.2.1. The operating system that I use is macOS Catalina, but I did a test also with MCUXpresso on Ubuntu 18.04 virtual machine. The firmware of the mbed NXP LPC1768 is the last version (141212) taken from the official Mbed website (os.mbed.com/handbook/Firmware-LPC1768-LPC11U24). The debug configuration that I use is the LinkServer C/C++ (NXP Semiconductors) MCU Application.
Firstly I tried to run some demo projects with an ethernet interaction taken from LPCOpen. All the projects build without errors or warning, but I’m not able to make it works. The freertos_blinky project works well: I can run and debug it. However the periph_ethernet, webserver, webserver_freertos, lwip_tcpecho_freertos, lwip_tcpecho_sa and in essence every demo project with an ethernet communication start to run, but when I try to stop or pause the execution this is the message error that I catch and the debug session closes:
Then if I try to rerun the project the “Cannot halt processor” console error reappeared and after this error I become no longer able to test any project on the LPC1768 with MCUXpresso, because if I try to run any project, the error always return.
The only way to recover the LPC platform is to use MBED Studio to build a .bin execution file, and load it in the device driver of LPC1768. After power-cycle the board by disconnecting and reconnecting the cable, I can still use MCUXpresso to run projects.
I also tried an ethernet demo project with mbed-os, using Mbed Studio 1.3.0.4, and in particular the mbed-os-example-sockets project. With Mbed everything works well: I can run codes and I see the platform successfully connected in ethernet and exchanging messages over the network. Therefore it’s not a problem of the board…
Why can’t I correctly run a project with an ethernet connection in MCUXpresso? Why did I obtain this “Cannot halt processor” error? How can I develop a LPC1768 with FreeRTOS+TCP?
First, does this only happen when you are using Ethernet?
I don’t know, but will guess it is something to do with the debug interface setting. However, these are not projects that we provide, so I can’t check. If you have a project that works ok and one that doesn’t I would suggest comparing the respective debug configurations. Look for settings like how the board is reset by the debugger (soft, vector reset, etc.), vector catch settings, ensure “semihosting” is turned off, etc.
Yes, only the projects that are using Ethernet doesn’t work. In particular I just saw that these Ethernet projects stop responding on the Chip_ENET_Init(LPC_ETHERNET, true); function. This function is part of the lpc_chip_175x_6x library under the LPCOpen collection. Maybe I should try to ask to the LPCOpen guys.
I don’t think the problem is the debug configuration setting because the configuration is automatically generated when I click the debug button. I have never changed the debug configuration settings generated, but as you said I compared the debug configuration of the projects that work ok with the ones that don’t work, but the behavior is still the same.
I try to check the debug configuration settings. In the following image there are some settings that you named. The semihosting support was setted to On, I tried setting it to Off but nothing, I got always the same “Cannot halt processor” error.
If I understand your post correctly the issue occurs when you call Chip_ENET_Init(LPC_ETHERNET, true);. Is that called before or after the FreeRTOS scheduler is started? If before, then it could possibly be caused by interrupts being disabled if Chip_ENET_Init() is using interrupts. Interrupts are deliberately left disabled between the first call to the FreeRTOS API and the first task starting, so you could move the call to Chip_ENET_Init() to before any calls to the FreeRTOS API.
Yes, the Chip_ENET_Init() function uses interrupts and I try to put it both before the vTaskStartScheduler() call and also in a task, but the problem remains, and the debug session always halt on Chip_ENET_Init() function.
In particular, after some debugging, I found that the error jump out in a specific instruction inside Chip_ENET_Init() function and, at first, the error reported is for a memory access in the 0x50000000 address, that is the ethernet peripheral base address.
However this problem is not FreeRTOS related, because if I try to call the Chip_ENET_Init() function in a project without FreeRTOS, I see the same error. Moreover I found a similar issue in NXP Community here, in which I am interacting.
Instead I tried to create a new project with FreeRTOS+TCP, that doesn’t use the EMAC driver (found in OpenLPC, named lpc_chip_175x_6x) with the Chip_ENET_Init() initialization function, but uses a similar driver (named lpc17xx.cmsis.driver.library) with EMAC_Init() initialization function. My FreeRTOS+TCP project blocks on the configASSERT at the end of xNetworkInterfaceInitialise() function as showed below:
As you can see, the xStatus is generated by EMAC_Init() call, that for some reason return an error.
Could be this error correlated with the main problem? In this case I don’t have the debugger freeze or stopped in a strange error as before, but, even if the EMAC drivers are different, the problem is always generated by the EMAC driver initialization function, that both uses the 0x50000000 ethernet peripherals base address. I don’t think it’s a coincidence.
