Bootloader / Security

[Stu]

Hello,

Just wonder if anyone can help. In some products we have implemented a bootloader for programming the flash of a GB60 which was downloaded from the freescale web site. The security bits for the NVOPT in the bootloader are set to not secure. So when I change them to secure the bootloader doesnt seem to work anymore. Is it the case that you cannot have a bootloader and have a secure micro at the same time?

Thanks

Stuart   

[ok2ucx]

Hi,

there's no reason for bootloader failing to work under secured conditions. The bootloader is application just like any other, the only line to be changed is the following:

NVOPT_ROM:  SECTION
NVOPT   DC.B %00000000 ; backdoor disable, redirection enable, secured flash [last 00]

Having this value in NVOPT secures the S08 after Reset (no further BDM access to Flash/Ram). Tested. Bootloader and loaded application do communicate/work.

The bootloader itself allows (if compiled) reading of Flash for purpose of verify-after-write. This should be disabled using:

RCS_ENA     EQU     0      ; READ COMMAND SUPPORTED? (0 NO)

otherwise anybody can read Flash using AN2295 bootloader Read command thus compromising NVOPT security.

Hope it helps too,

regards, Pavel, ok2ucx (AN2295 bootloader developer)

Freescale Czech System Center,

Roznov p.R., Czech Republic, EU

[Stu]

Hi,

Thanks very much for your help. I'll give it a go.

Stuart

[Cmux]

I am quite new to programming using bootloader so please don't mind elementary doubts. I read in the AN2295 document that the MCU needs to be programmed with the bootloader software once using BDM interface. Having done that do I need to include the bootloader source code anywhere in my user-code to enable bootloader programming? Or it resides permanently in the protected flash memory of the MCU until I re-program it with BDM interface?

-- 

Cmux

[ok2ucx]

Latter option is right. AN2295 bootloader has been designed with 'user code independence' in mind. The user code does not know anything about the bootloader (just taking in account few limitations given). The user code simply needs to be squeezed into lesser memory and FPROT/FOPT options ignored. Also the internal oscillator TRIM value is programmed together with the bootloader, not with the user code.

Vice versa, the bootloader does not know anything about the user code. Bootloader code is Flash protected (where applicable), occupying the top memory area, completely resident till erased via the BDM.

Pavel, ok2ucx (AN2295 bootloader developer)

Freescale Czech System Center,

Roznov p.R., Czech Republic, EU

[Cmux]

Thanks for your reply. Another doubt just came up. As you said that the internal oscillator TRIM value is set by the bootloader code, can my user-code still select an external oscillator as the clock source and disable the internal reference clock thus overriding the bootloader clock selection?

-- 

Cmux

[ok2ucx]

Sure, your application can do *almost* anything with the MCU, no limitations. Again, the user code starts to execute with very minimum changes (against reset-state). Just look what happens between ILOP-reset and user application:

main:
    LDA     SRS         ; fetch RESET status reg.
    TSTA                ; check if zero (this happens if RESET pulse is too short)
    BEQ     slfprg      ; if so, jump to self programming               
    AND     #%10000000  ; mask only POR RESET source     
    BNE     slfprg      ; any of these sources, go to self programming
  
    LDHX    #(REL_VECT|$00FF)&$FFFE
                 ; there should be relocated reset vector of the new app.
    LDA     ,X
    PSHA
    AND     1,X
    LDX     1,X
    PULH
    INCA
    BEQ     slfprg      ; don't jump if empty vector
    JMP     ,X  ; jump to relocated application

Simply, SRS is read and few instructions executed, all registers are in reset state, including internal oscillator ones.

Pre-set internal trim value is the one stored in Flash (typically during initial Flash programming) and it's the user application responsibility to copy this value to run-time TRIM register, where it effectivelly controls internal oscillator.

Pavel

[Cmux]

I have made the hardware for bootloading my S08. I am facing two problems with it.

1.I flashed the bootloader code onto the microcontroller and then used the bootloader GUI to program the chip. It did fine but after that I was unable to flash the chip again using the bootloader GUI. The program gets stuck waiting for reset ACK. I read the flash to check if my user-code had accidently erased the bootloader (inspite of the flash protection) but it was not the case. If I flash the bootloader source code again then I am able to bootload my user code into it.

2. The above behaviour is not repeatable though. Most of the times the bootloader GUI gets stuck waiting for reset ACK. 

What might I be doing wrong? I don't doubt the hardware connections because I was able to bootload the chip a couple of times. Loose connections, I have checked.

-- 

Cmux

[Cmux]

An update:

The erratic behaviour (unpredictable programming) was because of my serial port being left open. That problem is solved. But the main problem is still there. After every time I program using the bootloader GUI, I have to flash the bootloader source again using Multilink. The flash contains both the sources (user and bootloader). I also checked where the PC is pointing to so as to verify that it indeed points to the bootloader area in the flash. In both cases (after flashing bootloader using Multilink and after programming the user code using bootloader GUI) the PC points to the same address i.e. FE19. Yet the second time I try to bootload the chip, the GUI keeps waiting for reset ACK.

Can anyone help me out here?

-- 

Cmux

[ok2ucx]

This behaviour may be related to the following 'lazy' hw issue: see this link.

The reason why initial programming (without any user code) vs. sequential programming (some user code already programmed) differs is that:

- without any user code, ACK char is being transmitted periodically, so if first character is lost, any subsequent char is properly received (by PC) and the bootloading could start.

- with the user code, ACK chat is sent out only once, then (once the communication is not established), user code is started.

Pavel

[tonyp]

Don't have the docs infront of me to check the finer details but I think you should be able to bypass any security problems by using the backdoor key mechanism (i.e., writing a 64-bit value before attempting further access to secured resources).  The backdoor key can either be transmitted from the PC to the bootloader, or be pre-installed along with your bootloader to bypass security.

[okasional]

Not clear about the relative advantages of initially programming the flash with a bootloader versus via the BDM.  Even in a production environment I would expect the BDM serial protocol to be fast enough.  Can someone enlighten me?

[Stu]

hi,

We use the bootloader so customers can upgrade as the bootloader app is free and all you need to program is a serial port. I use a PnE BDM programmer during development.