• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 83 subscribers
  • Views 291 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

F28M35H52C: SW reset after flash programming does not raise SYSCTL_CAUSE_SW reset cause

Robert Tsien
Prodigy 165 points
Part Number: F28M35H52C

Hi,

I'm porting some existing bare metal application to TI-RTOS. The chip we use is the F28M35H52C1.

The code has firmware upgrade feature which resets the CPU after programming new firmware by using SysCtlReset().

My question is; why is the SYSCTL_CAUSE_SW not set after it resets? This is specifically the case after programming the flash. If the flash programming routines are commented out and not called, the SysCtlReset() works fine and CPU resets correctly with the SYSCTL_CAUSE_SW set when it boots. However if the programming of flash is done, the CPU resets , but SYSCTL_CAUSE_SW isn't set. It gets stuck waiting for the C28. To get out of this I had to cycle the power, where the new programmed firmware will boot correctly.

As part of the start up code early in main(), the SysCtlResetCauseGet() is checked against a software reset SYSCTL_CAUSE_SW where it would send a reset to C28 and synchronise with the C28 startup. Code follows:

Fullscreen
1
2
3
4
5
6
7
8
9
10
· // In case of software reset, control and/or analog system need to be manually reset.
· if (SysCtlResetCauseGet () & SYSCTL_CAUSE_SW)
· {
· · SysCtlResetCauseClear (SYSCTL_CAUSE_SW);
· · unsigned long ulResetConf = SYSCTL_CONTROL_SYSTEM_RES_CNF | SYSCTL_ANALOG_SYSTEM_RES_CNF;
· · SysCtlSubSystemReset (ulResetConf);
· }
· //· Send boot command to allow the C28 application to begin execution
· IPCMtoCBootControlSystem(CBROM_MTOC_BOOTMODE_BOOT_FROM_FLASH);
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
All these are ported from existing code in bare metal which works well. However with the code ported to TI-RTOS, it doesn't seem to see SYSCTL_CAUSE_SW and hence getting stuck in the IPCMtoCBootControlSystem() call. Additionally, if I just ignore the C28 and the call to IPCMtoCBootControlSystem() commented out, reset and execution of the M3 code works perfectly after programming the flash.
Any ideas or pointers?
Thanks,
Robert
  • 0
    TI__Guru 53085 points

    What are your Boot module settings in your SYS/BIOS cfg file? I'm wondering if there's maybe some conflict between what SYS/BIOS is doing to try to Boot the device and what your application code is doing.

    Whitney

  • 0
    Prodigy 165 points

    Here is the condensed cfg. I don't see any boot configs. It was basically taken from a min project.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    var Clock = xdc.useModule('ti.sysbios.knl.Clock');
    Clock.tickPeriod = 10;
    var Defaults = xdc.useModule('xdc.runtime.Defaults');
    Defaults.common$.namedModule = true;
    var Error = xdc.useModule('xdc.runtime.Error');
    Error.policyFxn = Error.policyDefault;
    Error.raiseHook = Error.print;
    Error.maxDepth = 2;
    var halHwi = xdc.useModule('ti.sysbios.hal.Hwi');
    var m3Hwi = xdc.useModule('ti.sysbios.family.arm.m3.Hwi');
    halHwi.checkStackFlag = true;
    m3Hwi.enableException = true;
    m3Hwi.nvicCCR.DIV_0_TRP = 0;
    m3Hwi.nvicCCR.UNALIGN_TRP = 0;
    var Idle = xdc.useModule('ti.sysbios.knl.Idle');
    var BIOS = xdc.useModule('ti.sysbios.BIOS');
    BIOS.assertsEnabled = true;
    BIOS.heapSize = 1024;
    BIOS.includeXdcRuntime = false;
    BIOS.libType = BIOS.LibType_Custom;
    BIOS.runtimeCreatesEnabled = true;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Also I do not think it is related to boot options because the issue happens when flashing an existing (working) bare metal firmware too. So that's not booting into an rtos app.

  • +1 in reply to Robert Tsien
    TI__Guru 53085 points

    It should be using the default Boot module settings then. I also did a quick search through the SYS/BIOS code and didn't see it doing anything to potentially clear the reset cause.

    What is SysCtlResetCauseGet returning in this scenario? Just 0? Where exactly in IPCMtoCBootControlSystem() is it getting stuck? What is the C28x doing?

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 165 points

    Apparently nothing to do with reset cause. I still have the issue but it's more to do with optimisation. If everything was sitting at optimisation setting 0 (register), it's all working nicely (fw updates to rtos or bare metal versions). The moment I up the optimisation to 1 (Local) or higher , the the firmware update and reset procedure would brick after the reset. Is the problem pre-update or post-update is very hard to diagnose. The moment cpu resets after the fw flash, the debugger is lost. 

    I would like to think I can fix it pre-update, because all existing versions of bare-metal firmware has higher optimisation that will brick when attempting to update the fw to.

    Strange thing is whatever target fw I was attempting to flash to is successful. It just needed a power cycle.

  • 0 in reply to Robert Tsien
    Prodigy 165 points

    Just an update. I did resolve my issue. Turns out my SysCtlReset() wasn't in ram.