Has anyone used the LwIP Raw API with RTOS?

[willcfj]

I'm starting to get comfortable with CMSIS-RTOS (and the STM32 implementation "uniqueness's" :) ), and next phase is adding LwIP support to my project. My IP needs are fairly simple, so was originally planning on using the Raw API. I see using CubeMX that if FreeRTOS is enabled, it forces the RTOS-based LwIP implementation.

I'm only using the RTOS for some high level stuff, so it's timer tick is 10ms instead of 1ms. I was trying to keep it mostly out of the way. Is trying to ignore the RTOS mode a bad idea given it is there already? Should I just use RTOS mode and deal with the overhead? I am concerned about flash space, I'm on an H750 with only 128KB of flash and it's almost 50% used in early stages of the project.

Any insights appreciated, thanks in advance.

will

[Pavel A.]

>  I'm on an H750 with only 128KB of flash and it's almost 50% used in early stages of the project.

Here's a useful tip for you: as already noted by others here, H750 may have more than one flash page.

Test pages 1-7 in bank 1 (erase and write) . You'll find at least one more usable page.

Of course these extra pages come without any warranty from ST...

-- pa

[willcfj]

PIranha:

Just a follow-up to say thanks. I finally got the code working. The biggest issue was (and still is) definitely memory management. I'm using the Atollic IDE and for that IDE, all the parameters you carefully set up in CubeMX for Ethernet bufers are just ignored and they end up in DTCM! You have to go manually edit the loader file All fixable once you know you need to, but just takes time to figure it out. Right now I need to disable the data cache entirely for things to work, so know I have some more sleuthing to do to figure out how to tweak the MPU settings. All the examples for the H7 are for the H743, so need tweaking for the H750 memory map. Once I sort it out, I should have a much better feel for memory usage too.

Thanks again for the guidance. Now comes the stage as you point out above where you start taking the HAL code and optimizing it for you own use.

will

[willcfj]

More for others than Piranha:

This is just concluding this thread with the "final issue" to get Ethernet working on the STMH750. I really should create an independent post, and hope to do that a bit later, there was a lot to figure out that if I post it, can save others time.

The last issue was indeed memory management. The program only worked if I disabled data caching entirely. With some sleuthing it turned out to be the main ran_heap (defined in mem.c) used by LwIP. It is just put in "regular" RAM without any special handling. When data is ready to be sent to the Ethernet controller in ethernetif.c in low_level_output(), there is no cache flushing before calling HAL_ETH_Transmit(). There is cache invalidating for Ethernet reads, just not for writes which is weird. Anyhow, in low_level_output(), the best place to flush the cache seems to be in the for loop near the top. Code snippet below with the only change being the cache flush line with the //WMB comment. This isn't a great solution as this code will get erased on every CubeMX build, so need to come up with a better long term solution.

  for(q = p; q != NULL; q = q->next)
  {
    if(i >= ETH_TX_DESC_CNT)	
      return ERR_IF;
    
    Txbuffer[i].buffer = q->payload;
    Txbuffer[i].len = q->len;
    SCB_CleanDCache_by_Addr((uint32_t *)Txbuffer[i].buffer,Txbuffer[i].len); //WMB
    framelen += q->len;
    

Given the above solution, I'm curious how the example code works. I can't run it as it's for a different MCU (STM32H743) on a different platform (STM32H743I-EVAL), but seems as though it should have the same problem.

Thanks again for the guidance Pavel and Piranha. Nice to have this working finally. Now, I need to decide if I go back to answering the original question of going back to the Raw API or just sticking with Netconn

will