• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 32 subscribers
  • Views 470 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.

TM4C1292NCPDT: program is getting crashed when we are exposing our device to 10 degree celsius and Relative humidity of 50%

vamsi challa1
Prodigy 140 points
Part Number: TM4C1292NCPDT
Other Parts Discussed in Thread: TM4C129XNCZAD

Programming is getting crashed after configuring PM7 (pinnumber 71 ) for PMW 

void
TimerConfigure(uint32_t ui32Base, uint32_t ui32Config)
{
//
// Check the arguments.
//
ASSERT(_TimerBaseValid(ui32Base));
ASSERT((ui32Config == TIMER_CFG_ONE_SHOT) ||
(ui32Config == TIMER_CFG_ONE_SHOT_UP) ||
(ui32Config == TIMER_CFG_PERIODIC) ||
(ui32Config == TIMER_CFG_PERIODIC_UP) ||
(ui32Config == TIMER_CFG_RTC) ||
((ui32Config & 0xff000000) == TIMER_CFG_SPLIT_PAIR));
ASSERT(((ui32Config & 0xff000000) != TIMER_CFG_SPLIT_PAIR) ||
((((ui32Config & 0x000000ff) == TIMER_CFG_A_ONE_SHOT) ||
((ui32Config & 0x000000ff) == TIMER_CFG_A_ONE_SHOT_UP) ||
((ui32Config & 0x000000ff) == TIMER_CFG_A_PERIODIC) ||
((ui32Config & 0x000000ff) == TIMER_CFG_A_PERIODIC_UP) ||
((ui32Config & 0x000000ff) == TIMER_CFG_A_CAP_COUNT) ||
((ui32Config & 0x000000ff) == TIMER_CFG_A_CAP_COUNT_UP) || // Missing from OEM version
((ui32Config & 0x000000ff) == TIMER_CFG_A_CAP_TIME) ||
((ui32Config & 0x000000ff) == TIMER_CFG_A_CAP_TIME_UP) || // Missing from OEM version
((ui32Config & 0x000000ff) == TIMER_CFG_A_PWM)) &&
(((ui32Config & 0x0000ff00) == TIMER_CFG_B_ONE_SHOT) ||
((ui32Config & 0x0000ff00) == TIMER_CFG_B_ONE_SHOT_UP) ||
((ui32Config & 0x0000ff00) == TIMER_CFG_B_PERIODIC) ||
((ui32Config & 0x0000ff00) == TIMER_CFG_B_PERIODIC_UP) ||
((ui32Config & 0x0000ff00) == TIMER_CFG_B_CAP_COUNT) ||
((ui32Config & 0x0000ff00) == TIMER_CFG_B_CAP_COUNT_UP) ||
((ui32Config & 0x0000ff00) == TIMER_CFG_B_CAP_TIME) ||
((ui32Config & 0x0000ff00) == TIMER_CFG_B_CAP_TIME_UP) ||
((ui32Config & 0x0000ff00) == TIMER_CFG_B_PWM))));


//
// Disable the timers.
//
HWREG(ui32Base + TIMER_O_CTL) &= ~(TIMER_CTL_TAEN | TIMER_CTL_TBEN);

//
// Set the global timer configuration.
//
HWREG(ui32Base + TIMER_O_CFG) = ui32Config >> 24;

//
// Set the configuration of the A and B timers and set the TxPWMIE bit.
// Note that the B timer configuration is ignored by the hardware in 32-bit
// modes.
//
if(NEW_TIMER_CONFIGURATION)
{
HWREG(ui32Base + TIMER_O_TAMR) = (((ui32Config & 0x000f0000) >> 4) |
(ui32Config & 0xff) |
TIMER_TAMR_TAPWMIE);
HWREG(ui32Base + TIMER_O_TBMR) = (((ui32Config & 0x00f00000) >> 8) |
((ui32Config >> 8) & 0xff) |
TIMER_TBMR_TBPWMIE);
}
else
{
HWREG(ui32Base + TIMER_O_TAMR) = ((ui32Config & 0xff) |
TIMER_TAMR_TAPWMIE);
HWREG(ui32Base + TIMER_O_TBMR) = (((ui32Config >> 8) & 0xff) |
TIMER_TBMR_TBPWMIE);
}
}

Configuration is done as below

"static PwmTimerTiva condoPwm(TIMER5_BASE, (TIMER_CFG_SPLIT_PAIR | TIMER_CFG_A_PWM | TIMER_CFG_B_PWM), TIMER_B, BSP_CLOCK_FREQUENCY);"

This behavior is only observed when the device is exposed to 10 degree celsius and Relative humidity of 50%, It is working fine with normal room temperature.

Can I know the operating range of relative humidity of this part?

  • 0
    TI__Guru*** 135355 points

    Hello Vamsi,

    Our MCU reliability tests for biased humidity are run at 85% RH, so 50% should not cause any issue. The temperature piece is interesting here too. I think there is something going on with the hardware that is causing this to occur. If the code runs fine at room temperature then that means the software should be good.

    My first question here would be how are you sure it is that output that is crashing the program? Have you removed the code for that and re-run the test and found the board works then?

    And how many boards are showing this issue? Just one or multiple?

    Because right now I'm thinking right now along the lines of maybe a cold solder joint somewhere and the temperature / humidity then is impacting it.

    If you have multiple boards, have you done an ABBA swap test? Also if multiple boards, how many are failing total?

    Lastly, what specific behavior are you seeing with the 'crash'? Are you able to connect to JTAG still and debug? Does it hang? Go in Fault ISR? 

  • 0 in reply to Ralph Jacobi
    Prodigy 140 points

    Hi Ralph,

    Thank you for quick reply.

    I want correct one thing we have done 10 degree Celsius and 90% RH sorry for the wrong RH value(condensing type) in my previous post.

    Yes controller is getting power and I am able to connect debugger through JTAG. Yes when I removed that line of code I am able to navigate to my application code and code is running fine both in debug mode release mode.

    When I add that line of code (configuring pin 71 as pwm output) after writing the configuration data in TIMER5 config register it is getting crashed. This we observed in two boards. One of them resumed after exposing to normal room environment but other one resume after soldering touchup.

    Even some salt deposits which my cause shorting, I have one question why the firmware is crashing?

    Crashing means it is not going to fault ISR. I thing it is restarting again and again.

    I am getting below messages

    Cortex_M4_0: Error: Stat [ JLINKARM_IsHalted() call ] failed!
    Cortex_M4_0: Trouble Halting Target CPU: Halt failed!

    Thanks and Regards,

    Vamsi

     

  • 0 in reply to vamsi challa1
    TI__Guru*** 135355 points

    Hello Vamsi,

    Thank you for these added details here. The behavior is much clearer.

    Given the behavior is linked to one pin and the solder touchup helped resolve it, that would seem to indicate potentially having extra current draw trigger a brown-out reset. This could be due to just pin 71 drawing too much current or due to a faulty connection on the PCB for power or ground.

    Here are some tests to do in order to see if the brown-out reset is occurring:

    1. Monitor VDD for any drops / glitches
    2. Check the RESC and PWRTC registers after recovering operation and look for:
      1. RESC --> BOR flag
      2. If BOR set, PWRTC --> Which voltage domain experienced the BOR

    If you are seeing a BOR, then I would investigate the PCB further. Possible causes could be solder issues for the pins on the voltage domain that the BOR is occurring or issues with the device at Pin 71 is connected to causing excess current draw in the high humidity situation. Keep in mind that perhaps a short / least resistive path may have become available due to the low temperature.

    Regarding the humidity itself, yes 90% is higher than we are testing for however that brings up the question of how long is the soak at these conditions? In general we would expect it to take hours to have any impact. Furthermore how quickly after removing from humidity does the part need to recover? Is it kept at the same temperature during that time frame? Has the board passed testing at the same temperature and less humidity?

  • 0 in reply to Ralph Jacobi
    Prodigy 140 points

    Hi Ralph,

    Thank you for suggesting tests to debug the issue.

    We have tested three devices with 10 degree and 85% RH and 40 degree 85% RH. Soaking is 7 to8 hours.

    The board is kept horizontal. there is one more controller(TM4C129XNCZAD), it is placed vertically and properly shielded, We didn't observed much issues with this ( TM4C129XNCZAD).

    After exposing to 25 degree for one the board with issue is getting resumed.

    Conformal coating was not done yet.

    Do you suspect condensation or moisture is causing issue? 

    Thanks and Regards,

    Vamsi

  • 0 in reply to vamsi challa1
    TI__Guru*** 135355 points

    Hello Vamsi,

    If there is condensation on the PCB directly then it is possible that the layout has a location where a short between power and ground could be formed which would reset the device.

    The silicon package itself would not be impacted by a soak of that length, so the question is what is going on with the PCB that is causing the issue here and I think the reset register tests will be important for you to understand the fail case in more detail so you can then look into the hardware further to find the ultimate root cause.

  • 0 in reply to Ralph Jacobi
    Prodigy 140 points

    Hi Ralph,

    Thank you for your inputs. We will consider all of them.

    Thanks and Regards,

    Vamsi