llMicrontroller is going into ISP mode during start up condition in few random cycles

[ShashankV]

Hello,

1. We are using LPC1837JBD144 micro controller in Key panel. During the startup there is a function call (Keypad_led_init()) to switch off the LED which are ON (default condition) during the POR. In some random cycle these LED's are not turning OFF(Keypad_led_init()) does not work and micro controller maybe moving into ISP mode which is prohibiting to execute the normal code.

2. There is a function SystemCoreClockUpdate() which is called before the Keypad_led_init()).

Question is what is the use of the SystemCoreClockUpdate()  ?

Is there any condition which is forcing the micro controller to move in ISP mode?

[Wajahat_Sharif]

Hi @frank_m , experiencing a similar issue with the same microcontroller. 

Sometimes, the keypanel is not being detected by the system because the microcontroller code is not being executed. Or maybe it is going into ISP mode somehow. The P2_7 pin is maintained high at reset, so this pin is not triggering the ISP mode for sure... 

Is there a possibility that sometimes because of noise generation at some pins, the microcontroller is going into ISP mode or not executing the code at all?

And if the code is not being executed, what possible states in which the microcontroller can go in other than ISP or boot mode?

Any help is greatly appreciated. Thank you!

[frank_m]

First, I don't have experience with the LPC1837, but with other LPCs and MCUs of other vendors.
And all use basically the same method, with some differences in details.

To quote from the datasheet again:
Several other boot modes are available if P2_7 is LOW on reset ...
...the states of the boot pins P2_9, P2_8, P1_2, and P1_1 determine the boot mode.

Which means you need to pull P2_7 low to get into any other bootmode than Flash. And the state of pins P2_9, P2_8, P1_2 and P1_1 determine what mode is actually executed.
Which means the actual boot mode depends on the state of said pins.

> The P2_7 pin is maintained high at reset, so this pin is not triggering the ISP mode for sure... 

I would first check the manual/datasheet when the mode pins are scanned. I would expect at the L/H transition of the reset siganl. And then probably check the hardware, i.e. measuring with a scope, until you got said problem case.

I know of MCUs that calculate a checksum over the user app Flash on their own and store it internally. At startup, the ROM code runs a checksum test and branches into ISP mode if the checksums do not match, i.e. the application seems corrupted.
You would need to check the datasheet/manual to see if the LPC1837 has such a feature.

[ShashankV]

Hi Frank,

Thank you for quick reply.

but assuming if there is a checksum code that runs and if it is corrupted than it won't be corrected into the next cycle right?

This phenomenon of Micro controller getting hanged during startup is having once in random cycles like 

once in 100 or once in 2000 cycles.

[frank_m]

> but assuming if there is a checksum code that runs and if it is corrupted than it won't be corrected into the next cycle right?

No, we are talking about different things here.
What you mean is ECC, which most MCUs nowadays implement. This feature can detect and correct certain memory errors at runtime, without the core itself noticing it.
What I meant is ROM-based code that can run a checksum calculation over the whole user flash, to detect corruptions/modifications. Not many MCUs implement this feature,  but it is useful in an environment where safety or security requirements must be observed.
As said, I don't know if your MCU implements this feature, you need to study the datasheet.

But other reasons for occasional fails are possible.

If one of the other mode pins is used for interface functionality in your application, external signals (like ongoing serial communication on a bus system) could have an effect during startup.

Electrically improper connections with other systems can cause shifts in electrical potentials, and thus create stray signals. A common problem I have/had with CAN-bus systems.

Your PCB / hardware design might not be fully stable. Tests at increased temperature would reveal issues.
The same goes for internal instabilities. The clock tree setup can fail occasionally if you are at the limit, or memory access can fail as well. Elevated temperatures should increase the error probability, and reducing core speed and / or relaxing memory wait state settings would fix it.
Issues with the quartz, MCU clock input wiring and PCB design might also cause issues, but I am no hardware expert.

By the way, I would make sure if the MCU is really starting into ISP mode, or going into a hardfault or lockup.
If the latter is the case, no ISP access (serial interface ?) is possible without a power cycle.

[frank_m]

> 1. We are using LPC1837JBD144 micro controller in Key panel

A custom board, I suppose.

Quoting from the datasheet, section 7.11 :

The default boot source is the flash memory. Several other boot modes are available if P2_7 is LOW on reset depending on the values of the OTP bits BOOT_SRC. If the OTP memory is not programmed or the BOOT_SRC bits are all zero, the states of the boot pins P2_9, P2_8, P1_2, and P1_1 determine the boot mode.

It seems you left the mentioned mode pins dangling.
Use pull-up/pull-downs to get a Flash boot by default, and plan a jumper field to enforce a ROM/ISP bootup when you need it.
That is the way it is usually done.

[ShashankV]

Hi Frank,

Thank you for the reply.

But as you can see in the attached image of the schematic, those 4 pins have been via jumper made to ground.

Please can you also answer to @Wajahat_Sharif  query.

Your help is highly appreciated.

[ShashankV]

1. Here in the attached waveform green colour is user switch pin connected to P2_7 GPIO_7().

2. Pink colour is POR (power on reset) signal.

3. Yellow colour is active low LED signal.