• State TI Thinks Resolved
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 13 replies
  • Answers 1 answer
  • Subscribers 83 subscribers
  • Views 421 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.

TMS320F280037C: Inquiry on F280037C Reset Issue and Temperature Impact

Reddy manohar
Prodigy 20 points
Part Number: TMS320F280037C


Tool/software:

We are currently experiencing unexpected resets with our F280037C microcontroller while operating around 80°C ambient temperature environment. We noticed that there was a loss of CAN communication for a period, which subsequently reestablished.

To diagnose the reset cause, we have gone through the RESC status register documentation and SysCtl_getResetCause(void) but are unsure how to read this information using CCS code or directly from memory. Any guidance on this would be greatly appreciated.

Additionally, we would like to understand the potential effects of high ambient temperatures on the reset behavior of the microcontroller.

For reference, we are using the following ICs to power the microcontroller:

  1. INN3166C-H101-TL
  2. TPS560430XDBVR

 Any guidance on this would be greatly appreciated.

  • 0
    Prodigy 130 points

    Hi Reddy,

    I hope you don’t mind me jumping into your thread.

    Dear TI experts,
    I wanted to report that I encountered a similar issue with my F280039C at approximately ±80°C. I have verified the reset by checking the status of a GPIO pin.

    I also would like to understand the potential effects of high ambient temperatures on the reset behavior of the microcontroller.

    Thanks,
    Luiz



  • 0
    TI__Guru** 115431 points

    Hi

    Did you probe the XRSn pin of the device to see if device is going through reset cycle in this case ?

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 130 points

    Hi Vivek,

    In my case, I can't access the XRSn pin on the board with the issue. So far, I've only been able to replicate the problem on 1 board out of 7 samples.
    I connected to cJTAG and found that the program goes into ITRAP when the core temperature reaches 90 degrees.
    I’ve tried to track the code execution before the ITRAP, but I still can't find the one causing it. Here is the screenshot.

    The ITRAP did not occur on the other 6 samples.


    Regards,
    Luiz

  • 0 in reply to Luiz Ramelan1
    Prodigy 20 points

    Hi Luiz,

    In our case, the power board and control board were completely potted. We only have access via JTAG and CAN.

    Is there any other solution to check the problem?. Do u try any APIs  like SysCtl_getResetCause(void) ?

    Thanks,
    Reddy

  • 0 in reply to Luiz Ramelan1
    TI__Guru** 115431 points

    Hi Luiz,

    Would it be possible to swap the silicon from non working to working board. This is to check if issue is with Silicon or some variation of electric parameter on the board.   

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 130 points

    Hi Vivek,

    I'm checking through the available samples, and so far, I've only found the issue in 1 fully assembled board out of 11 samples. Swapping the MCU in this sample can't be done without compromising other components, so we can only access it through JTAG.

    Is there a way to use SysCtl_getResetCause to diagnose the ITRAP? Or do you have any suggestions on how to diagnose this via JTAG?

    Thanks,
    Luiz

  • 0 in reply to Vivek Singh
    Prodigy 20 points

    Hi Vivek,

    I am facing issues in clearing the reset cause once it is set.

    // Clear the given reset reasons. ************************
    SysCtl_clearResetCause(0x00000002U);
    SysCtl_clearResetCause(0x00000001U);
    """"""""""""""""""""""

    I am using this code to clear the causes, but I am unable to do so during runtime. Could you please provide us with the correct logic?

    Regards,
    Ramana

  • 0 in reply to Reddy manohar
    Prodigy 20 points

    Hi Vivek,

     We have tried the below logic for the reset cause clear.
        resetCauses_reason= SysCtl_getResetCause();


        if(Master_Cut_Off_Status==1 && RCR_flag==0)
        {

        // Clear the given reset reasons. ************************
        SysCtl_clearResetCause(SYSCTL_RESCCLR_POR | SYSCTL_RESCCLR_XRSN);
        resetCauses_reason= SysCtl_getResetCause();
        RCR_flag=1;
        }

        encode_ch_can_0x111_X_val_Model(&tsObject,resetCauses_reason);   // sending Via CAN
     
    However, we are unable to clear the register values. Can you please support us in this issue?
  • 0 in reply to Reddy manohar
    TI__Guru** 115431 points

    Are you able to clear it from CCS register view ? 

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 20 points

    Hi Vivek,

    We are creating a .out file and flashing it onto the hardware. We would like to read the reset cause only via CAN. Could you please let us know what code changes we should make to enable us to clear the registers and read them through CAN?

    Additionally, can we clear the RESC status register using the API SysCtl_clearResetCause(SYSCTL_RESCCLR_POR | SYSCTL_RESCCLR_XRSN)? I found a statement in the F280037C technical manual that mentions, "After a POR, the POR and XRSn bits in RESC are set. These bits are then cleared by the boot ROM. (3.4.4 Power-On Reset (POR))"

    Thank you!

  • 0 in reply to Reddy manohar
    TI__Guru** 115431 points

    Hi  Manohar,

    Reddy manohar said:
    found a statement in the F280037C technical manual that mentions, "After a POR, the POR and XRSn bits in RESC are set. These bits are then cleared by the boot ROM.

    Yes, that is correct. But if during application run reset happens due to XRSn then you'll see some bit getting set. When you read the reset cause status register, what value you are getting ? Since these bits are already cleared by ROM, how are you seeing then set ?

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 20 points
    Why do you want to clear the reset cause? 
    Reply: We are experiencing some issues during the charger operation, and we need to determine whether the problem is due to a CAN IC failure or an interruption in the  charger control card power supply. Here are the cases (assuming the reset cause CLEAR works):

    Case 1: Only a CAN issue and no power issue. This means the initial CAN value will be "3," and after clearing, it will be "0." It will remain at "0" only if CAN communication is subsequently reestablished, indicating that no power reset occurred.

    Case 2: Only a power issue. In this case, the initial CAN value will also be "3," and after clearing, it will be "0." If the power supply is subsequently reestablished, we will see the value return to "3."

    What value do you get when you try to get the reset reason the first time? 
    Reply: The value we are seeing via CAN is "3."


    Regards
    Ramana 
  • 0 in reply to Reddy manohar
    TI__Guru** 115431 points

    Manohar,

    Sorry for late reply. 

    Reddy manohar said:
    What value do you get when you try to get the reset reason the first time? 
    Reply: The value we are seeing via CAN is "3."

    I am not clear on above observation. You should not get this value as 3. Please check this again.

    Vivek Singh