• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 155 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.

EK-TM4C1294XL: Issue with SoftwareUpdateInit() in FreeRTOS – SoftwareUpdateRequestCallback() Triggered Without Magic Packet

Shravani E
Prodigy 10 points
Part Number: EK-TM4C1294XL


Tool/software:

Hello,

I'm referring to the "Ethernet Software Update Module" documented in SW-TM4C-UTILS-UG-2.1.4.178.pdf, located at C:\ti\TivaWare_C_Series-2.1.4.178\docs

In a bare-metal application, the firmware update over Ethernet works flawlessly using the bootloader and the SoftwareUpdateInit(callback_function) mechanism.

However, when I integrate the same code into a FreeRTOS-based application, I observe an unexpected behavior: The SoftwareUpdateRequestCallback() function is invoked continuously, even though no magic packet has been sent by the LM Flash Programmer or any host.

For debugging, I modified utils/swupdate.c to log received packets: UARTCharPut(UART4_BASE, MPACKET_MARKER);

Despite the fact that the received packet doesn't contain the MPACKET_MARKER (0xAA), the code still enters the associated if condition — including the MAC address matching conditions — as if the criteria were satisfied.

This behavior is not observed when using the same file and logic in bare-metal code.

It appears that somehow, in the RTOS environment, these conditional checks are not behaving as expected — even when their conditions are clearly not met.

My Questions:

  1. Could FreeRTOS be affecting memory, timing, or interrupt handling in a way that causes this issue?

  2. What would be the recommended approach for using SoftwareUpdateInit() in a FreeRTOS-based firmware safely?

  3. Is there any known interference between EMAC / lwip and FreeRTOS tasks/scheduler that might cause such false positives?

I would really appreciate any guidance on how to correctly implement the Ethernet bootloader with a FreeRTOS application, or how to debug the root cause of this misbehavior.

Thank you!

  • 0
    TI__Guru**** 191906 points

    Hi,

    Shravani E said:
    Despite the fact that the received packet doesn't contain the MPACKET_MARKER (0xAA), the code still enters the associated if condition — including the MAC address matching conditions — as if the criteria were satisfied.

    Are you adding code to the SoftwareUpdateUDPReceive() function? I think it is the SoftwareUpdateUDPReceive that detects and processes the incoming MAGIC packet. I don't know why it will mistakenly detect a non magic packet for remote firmware update. Which 'if' statement does it fail the detection?

      I'm not familiar with FreeRTOS that much. One thing for you to check is whether or not the vector table has changed because of FreeRTOS. If the vector table has changed, you need to make sure that you update VTABLE register accordingly. The bare-metal example has the vector table start at 0x0. But if your FreeRTOS application reallocate the vector table to somewhere else, you need to match VTABLE accordingly.

  • 0 in reply to Charles Tsai
    TI__Guru**** 191906 points

    Hi,

      I have not heard back from you. I will close the thread for now. If you have any update you can write to this post and the status will change to OPEN.