Higher temperature problems

[ken536]

I have a bootloader running on an LPC1752. This bootloader jumps to my main software after a few seconds.

This is already working for years! But recently we discovered a device that is not working properly because of a highter ambient temperature.

If the ambient is higher (~65Celcius) the bootloader starts, but on the moment it should switch to the main program it doesn't do anything. I can't connect using the jtag/swj debugger and really need to reset the device to start again.

If I flash my main program as start program instead of the bootloader the software does boot normally under the hot condition.

If the main software is already running before we get to the higher temperatures the devices runs as expected, meaning the problem is in the jump at line 39?

void NormalProgramCall(uint32_t *Address)
{
    
    // Disable all enabled interrupts in NVIC.
    NVIC->ICER[ 0 ] = 0xFFFFFFFF ;
    NVIC->ICER[ 1 ] = 0xFFFFFFFF ;
    NVIC->ICER[ 2 ] = 0xFFFFFFFF ;
    NVIC->ICER[ 3 ] = 0xFFFFFFFF ;
    NVIC->ICER[ 4 ] = 0xFFFFFFFF ;
    NVIC->ICER[ 5 ] = 0xFFFFFFFF ;
    NVIC->ICER[ 6 ] = 0xFFFFFFFF ;
    NVIC->ICER[ 7 ] = 0xFFFFFFFF ;
    
    //Clear all pending interrupt requests in NVIC.
    NVIC->ICPR[ 0 ] = 0xFFFFFFFF ;
    NVIC->ICPR[ 1 ] = 0xFFFFFFFF ;
    NVIC->ICPR[ 2 ] = 0xFFFFFFFF ;
    NVIC->ICPR[ 3 ] = 0xFFFFFFFF ;
    NVIC->ICPR[ 4 ] = 0xFFFFFFFF ;
    NVIC->ICPR[ 5 ] = 0xFFFFFFFF ;
    NVIC->ICPR[ 6 ] = 0xFFFFFFFF ;
    NVIC->ICPR[ 7 ] = 0xFFFFFFFF ;
    
    //Disable SysTick and clear its exception pending bit,
    SysTick->CTRL = 0 ;
    SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk;
    
    
    //Disable individual fault handlers if the bootloader used them.
    SCB->SHCSR &= ~(     SCB_SHCSR_USGFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk | SCB_SHCSR_MEMFAULTENA_Msk ) ;

    // Load the vector table address of the user application into SCB->VTOR register
    SCB->VTOR = ( uint32_t )Address ;
    
    // Set the MSP to the value found in the user application vector table.
    __set_MSP( Address[ 0 ] ) ;
    
    // Set the PC to the reset vector value of the user application via a function call.
    ( ( void ( * )( void ) )Address[ 1 ] )( ) ;           /////////// After this PC set the processor halts

}
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

[ken536]

Thank you for your response.

I've tried those settings (both in bootloader as firmware but it doesn't same to make a difference). Still the same problem

[victorjimenez]

Hello Ken, 

Do you have more boards running on the same conditions as the one that is not working properly? 

[ken536]

There are a lot of those boards. All of those boards don't work in those higher temperatures but when I test them here they do give the same issue.

So all off them have the problem but normally the ambient temperature is lower and the problem doesn't happen.

[victorjimenez]

Hello Ken, 

Based on the information you are providing it seems to be a hardware problem. I don't have enough information to say if the problem is on the NXP side or on your side.

Do you have a golden board? If so, could you please swap the MCUs between one of the boards that is presenting the issue and the golden board. This way we will be able to see where the issue goes. 

Regards, 

Victor.

[ken536]

The problem happens to all the board which normally work fine. I can't find any problem with is in hardware and tried different boards, so it's not just this single board.

[bernhardfink]

Hello Ken,

under the condition that you use the same devices on your board with the same software, the crash must be an analog problem, so let's hunt for this.

I would be interested in the exact instruction where the device hangs up or crashes. When you are in a debugger session you can also step through the assembler code. A screenshot of this section and the instruction where it happens would be perfect.

• A "digital" problem would be, if you jump with the change of the PC into a memory area which is not powered or generally not accessible.
• An analog problem would be, if during the valid access the addressed system is facing a problem, e.g. the immediate load causes a hickup of the internal regulators and the bus power falls below a critical level. This normally leads to a non-recoverable crash. This is sometimes very difficult to analyse, sometimes it's getting worse at colder temperature, sometimes at hotter temperature. Depends on the parasitic elements in you power supply concept.
  Inductors will dominate when it's colder, because signals will switch faster, capacitors on the other side lose will have less performance at higher temperatures.

For problems like this, you need to perform systematic tests with variations in

• Power supply level
• MCU cold but PCB hot and vice versa
• Improvements in ground connections
• System clock
• Key elements of your power supply structure (capacitors, inductors, regulators)

Regards,

Bernhard.

[victorjimenez]

Hello Ken, 

Maybe FLASHTIM bit field in FLASHCFG register is marginal, make sure it's set to 5 or "safe" for all conditions.

I recommend you to take a look to the user manual https://www.nxp.com/docs/en/user-guide/UM10360.pdf  under section 5.4 you will find the following table:

Hope it helps! 

Victor.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------