LPC55S2x: unable connect to UART ISP after secure boot enabling

cancel
Showing results for 
Search instead for 
Did you mean: 

LPC55S2x: unable connect to UART ISP after secure boot enabling

Jump to solution
272 Views
anton_hrabko
Contributor II

Hi, i'm working with LPC55S26 now and trying to configure secure boot

I tried a configuration:
PIN/DFLT in CMPA & CFPA: (1/1) -> (1/1) (to enable debug in secure boot)
DEFAULT_ISP_MODE = Auto ISP

I use a latest spsdk tool to generate CFPA & CMPA. After uploading with blhost and rebooting it is unable to connect via ISP (with ISP pin enabled). So why is LPC55S26 bricked?

The only strange thing I've found in this configuration is SOCU_PIN/SOCU_DFLT = FF 20 00 00, instead of required FF 30 00 00

 

Labels (1)
Tags (1)
0 Kudos
1 Solution
213 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @anton_hrabko 

Thank you for your patience,  as I have been checking internal documentation and doing tests on my side.

Regarding the issue , of having the MCU bricked. 

I think that , that what is causing you problems  ifsthe following configuration (1/1) for all of PIN/DFLT bits in the cmpa and cfpa files that you shared me, below an example:

diego_charles_0-1631588428984.png

Unfortunately, the 1/1 in this file will  brick the MCU. The best is to leave the PIN/DFLT as 0/0  , as my example in the above image.

That should not brick  the MCU, and let the debug access enabled.

*For further reference on enable secure boot, you may look to the AN12283 , and the elftosb gui . 

 

Regarding the  SOCU_PIN/SOCU_DFLT = FF 20 00 00 instead  FF 30 00 00

FF 20 00 00  is correct.  Let me explain.

1 First the endianness, I think you are using Little endian (LSB at the left  ) to express the value of the PIN/DFLT registers. 

2. The LSB corresponds to NIDEN and the MSB to MCM33_NIDEN. Below the bit position for every PIN/DFLT bit.

diego_charles_3-1631589012465.png

3. So , if   all of the bits above are set to one, we will obtain 0xFF2 ,  (or x2FF ) . Bit 8 , which  could give us 0xFF3 , is not used. Since ME and FA are shared in the  bit 7.

 

I hope this could help, let me know any other question you may have.

Thank you for your patience,

Diego.

View solution in original post

4 Replies
247 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @anton_hrabko 

I hope you are doing excellent.

Could you help me with the following questions?

1  Did you obtained the yaml files using the spsdk commands?

2 Which specific command options did you use to generate the bin files?

3  Is you purpose to have the MCU with only secure boot security feature  (at least during development ? )

4.  Are you still able to-reprogram the MCU by  SWD interface? This to see if we could re-gain access to the ISP by  restoring CMPA from the application itself.

 About SOCU_PIN/SOCU_DFLT = FF 20 00 00

 On my windows 10 machine using  your cmpa.yaml file  and the below commands: 

pfr generate-binary -c cmpa.yaml -o cmpa.bin 

or  

pfr generate-binary -c cmpa.yaml  -i -o cmpa.bin 

I was able to see  what you are mentioning  :  SOCU_PIN/SOCU_DFLT = FF 20 00 00, instead of required FF 30 00 00 . That means that the Mass Erase bit is not being set as expected from the yaml file . I will check this with my team.

All the best,

Diego

0 Kudos
242 Views
anton_hrabko
Contributor II

Hi, @diego_charles 

Thanks, i'm fine

1. For generation yaml files:
spsdk pfr get-cfg-template -d lpc55s2x -r 1b -t cfpa -o cfpa.yaml
spsdk pfr get-cfg-template -d lpc55s2x -r 1b -t cmpa -o cmpa.yaml

2. For generation bin files:

spsdk pfr generate-binary --user-config cfpa.yaml -o cfpa.bin
spsdk pfr generate-binary --user-config cmpa.yaml -o cmpa.bin 

3. Yes, the main aim is simply enable secure boot for development with ability for debug our code
4. No, i cannot reprogram device via SWD, because our sample firmware doesn't run with this configuration

The main problem is that ISP is disabled after uploading configuration with mistakes, i suppose that it's impossible, and i'm able to overwrite configuration via ISP (with ISP pin)

0 Kudos
214 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @anton_hrabko 

Thank you for your patience,  as I have been checking internal documentation and doing tests on my side.

Regarding the issue , of having the MCU bricked. 

I think that , that what is causing you problems  ifsthe following configuration (1/1) for all of PIN/DFLT bits in the cmpa and cfpa files that you shared me, below an example:

diego_charles_0-1631588428984.png

Unfortunately, the 1/1 in this file will  brick the MCU. The best is to leave the PIN/DFLT as 0/0  , as my example in the above image.

That should not brick  the MCU, and let the debug access enabled.

*For further reference on enable secure boot, you may look to the AN12283 , and the elftosb gui . 

 

Regarding the  SOCU_PIN/SOCU_DFLT = FF 20 00 00 instead  FF 30 00 00

FF 20 00 00  is correct.  Let me explain.

1 First the endianness, I think you are using Little endian (LSB at the left  ) to express the value of the PIN/DFLT registers. 

2. The LSB corresponds to NIDEN and the MSB to MCM33_NIDEN. Below the bit position for every PIN/DFLT bit.

diego_charles_3-1631589012465.png

3. So , if   all of the bits above are set to one, we will obtain 0xFF2 ,  (or x2FF ) . Bit 8 , which  could give us 0xFF3 , is not used. Since ME and FA are shared in the  bit 7.

 

I hope this could help, let me know any other question you may have.

Thank you for your patience,

Diego.

View solution in original post

195 Views
anton_hrabko
Contributor II

Hi, @diego_charles 

Thank you for your help! I'm glad to receive a detailed explanation.

I've reverted DFLT/PIN settings to default values (0/0), and everything is working now.