• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 30 subscribers
  • Views 343 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2634: Buffer size and lwip_write

rivrat
Prodigy 120 points
Part Number: AM2634

Tool/software:

Hello, 

I'm making use of the LwIP socket library incorporated in the SDK(version 9.01.00.41) to send and receive UDP packets over ethernet. My implementation resembles the netwroking/lwip/enet_cpsw_socket example in the SDK. I am seeing a problem where certain buffer sizes for the data being passed into lwip_write are causing failures in my application.

In the function that is sending packets, I declare static buffer of fixed size, populate it with the data I want to send (ensuring any previous data is cleared beforehand), and then pass a pointer to the buffer and the actual size of the data I've copied in to the lwip_write function. This works normally most of the time. However, I have found that for certain buffer sizes this causes an error. The symptoms of the error are that the other core on the chip crashes. I'm only making use of two cores at the moment, and it's the one that is not involved in ethernet that crashes. Also, the UART stops printing log statements. Everything else seems to work normally. I have also noted the following

  • We are using the LWIP API correctly - not using raw or sequential API calls in the wrong contexts
  • The buffer is declared with the attribute "section". The result is that the buffer is stored in the core's TCM region - so it is non-cacheable, and not close to the shared memory with the other core.
  • The buffer sizes that cause the issue follow a specific pattern: The size is offset by 2 bytes from a multiple of 32. So if {buffer_size}%32 is equal to 2 or 30, this failure will occur.
I have tried a couple of debug experiments, including
  • Adding an "aligned" attribute when declaring the buffer - I confirmed that this does align the buffer, but this does not change the result of the test
  • Attempting to read from the EDMA ERRAGG register to see if any errors are reported - I saw no errors 
  • Attempting to backtrace to find the route cause of failure in the core that fails - but it appears the issue is with a corrupted stack, and I could not route cause a specific instruction

Please let me know if you have any ideas for what the problem could be. 

Thank you!

  • 0
    TI__Genius 16492 points

    Hi Rivrat,

    1. Can you please let me know what parameter did you pass to the aligned() attribute. Was it 32B aligned or 64B or 128B?

    2. In your syscfg memory configurator, what is the stack size you are allocating for the application? Just making sure that the buffers you are declaring, if in case they are getting allocated in the .stack memory, you should have enough memory there. You can also confirm this by looking at .map file.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 120 points

    Hi Shaunak, 

    1. I passed in 32 to the aligned() attribute (I did also try it with 64)
    2. The amount of memory allocated to the TCMA region where the buffer is stored is 32KB. The stack size for the task that the function runs in is 2048B. The .stack segment in the .map file seems to be allocated 128KB. One other test I did try was increasing the buffer size, and as long as it followed the rule of not being 2 bytes offset from a multiple of 32, I did not have a problem. 

    Thanks!

  • 0 in reply to rivrat
    TI__Genius 16492 points

    Hi Rivrat,

    • 32B aligned should have worked. The default example sends a buffer of length 34B to the host. I tried running the out-of-box example and it worked as expected (34B buffer). Do you mind sharing your CCS project zip (or atleast the .out file incase the project is confidential) so I can try to reproduce this issue on my end? Might as well be an issue with memory configurator while placing the buffer in TCMA region.

    Regards,
    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 120 points

    Hi Shaunak, 

    I will try to get an .out file for you or another solution, but I wasn't able to complete this today. I will be away next week, but will do this when I return. 

    Thanks!

  • 0 in reply to rivrat
    TI__Genius 16492 points

    Hi Rivrat,

    Thanks for the update. Sure you can share it later.

    Best regards,

    Shaunak 

  • 0 in reply to Shaunak Deshpande
    Prodigy 120 points

    Hi Shauank, 

    I can't share the project code or .out at this time. I was wondering if you could share some information or resources about your comment about the memory configurator, or if there are any other suggestions or support you can offer. 

    Thank you! 

  • 0 in reply to rivrat
    TI__Genius 16492 points

    Hi Rivrat,

    1. I just wanted to compare the example.syscfg file for your application to the standard example in the SDK (since it sends a 34B buffer by default). Maybe this would help notice if we are missing any configuration in the application that is failing.

    2. In example.syscfg, pls compare the Enet (CPSW) module and Memory configuration (especially sections for pkt dma, cppi packet descriptors)

    3. Check incase of the buffer sizes which do not seem to work, you do not see any aborts.

    It might be a bit difficult to identify what the potential root cause could be without reproduction of the issues 

    Regards,

    Shaunak