• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 212 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.

TMS320F280039C: GPIO57 cannot read input data

Joe Ji
Expert 4190 points

Part Number: TMS320F280039C

Hi Experts

GPIO57 set as input in customer design, but after the firmware update without MCU reset, the GPIO57 cannot read input data. it can work after power cycle the MCU or reset the MCU.

I did some debug with customer

  • EALLOW/ EDIS are added in the configuration
  • GPIO10 is tested with same configuration, there is no issue
  • GpioCtrlRegs. GPBQSEL/GPBMUX2/GPBDIR registers are set as expected.

Could you please kindly share your insight on this issue?

Thanks

Joe

  • 0
    TI__Expert 7700 points

    Hi Joe,

    This symptom is very typical of a warm firmware update where the device is not reset, so GPIO state from the previous image remains active. If the previous firmware ever configured GPIO57 as a peripheral function / output / analog / locked pinmux, the new firmware may set the expected registers but still lose ownership of the pin internally until a reset/power-cycle returns everything to default.

    Check both GPBGMUX2.bit.GPIO57 and GPBMUX2.bit.GPIO57 are both 0.

    Make sure during the firmware update flow (no reset), run a full warm-start hardware initializing by disabling interrupts,  re-initializes system control/peripheral clocks and unlocks GPIO pin configuration and finally forces GPIO57 back to GPIO mode.



    Best Regards,

    Masoud

  • 0 in reply to Masoud Farhadi
    TI__Expert 4190 points

    Hi Masoud

    Thanks for supporting this case, force reset the GPyG and GPy Mux with bitfield operation makes no different for the result. but call the InitGpio() API can help.

    They need to keep some GPIO states during warning FW update, since the relay state cannot be changed. With this reason, InitGpio() cannot be applied to the real project, is there the API to init the single GPIO?

    Thanks

    Joe

  • +1 in reply to Joe Ji
    TI__Expert 7700 points

    Hi Joe,

    Yes, if InitGpio() fixes the issue, that suggests the problem is not only GPBMUX2/GPBGMUX2, but that some other GPIO state from the previous image is still being retained during the warm firmware update. In this case, a full device reset clears it, and InitGpio() also clears it by reinitializing the GPIO module.

    If they cannot call InitGpio() because some relay-related GPIOs must be preserved, the better approach is to do a targeted re-initialization only for GPIO57. There is no single legacy bitfield API exactly equivalent to Init only one GPIO, but this can be done by explicitly reapplying all relevant settings for that pin: unlock the pin config if needed then forcing GPIO function (GMUX=0, MUX=0) and digital mode and setting pad config / pull-up, qualification mode and direction as input.

    Best Regards,

    Masoud

  • 0 in reply to Masoud Farhadi
    TI__Expert 4190 points

    Hi Masoud

    Update the debug result, the GPIO configuration is correctly maintained in customer boot process, so once power up, the GPIO57 can work properly, now we copy the code to APP code, the GPIO57 can also works well after warm FW update.

    Thanks

    Joe