MKL17/27z experience a 3-5 Sec startup delay

[RGassmann]

Hi pgo,

recently I got the FRDM-KL27z-Board which I of corse wanted to use with the USBDM right away.
While the code of a simple flashing Led was working quickly, I noticed that the uC has a start delay of 3-5Sec. My first thoughts where that this has to do with the bootloader. Unfortunately that wasn't the case. After a discussion with a supporter I got a bin file which should work. Unfortunately my board still exerienced the delay. After this setback I tried to download the same s19/srec file with the OpenSDA. And voila it started up right away. And even my simple flashing led - Programm starts right away if I download it via OpenSDA but will experience a delay of 3-5Sec if downloaded via USBDM. This fact leads me to the assumption, that USBDM can not right to the entire flash of the uC (maybe some protection mechanism?). The same effect can be experienced on the MKL17 (which is nothing else than the MKL27 without USB).
Is this a known Issue to you? I would be glad if you could look deeper into this issue. If you need sample codes I'd be happy to provide you with my samples.
Looking forward to hearing from you.
Best regards,
Roman

[podonoghue]

Hi Roman,
I've used the KL27 with quite large programs without any trouble (that I'm aware of).
Could you post a project that illustrates this? Preferably a source code not just binary.
The programmer resets the target and such before running and this results in some delays. The reset time is configurable on the programmer and the KDS interface.

I have previously tested the stand-alone programmer by programming an image that fills the entire flash so I would not expect a problem (unless it has been introduced more recently).

I'll do some testing tonight.

bye

[RGassmann]

Hi pgo,
that's really odd. I never expected a different outcome depending on the programmer. But multiple tests tell me ohterwise. Regarding the delays from the resets (I am aware of them as I asked you to implement some time configurations quite a while ago:-)). Unfortunately the delay that I experience is not caused by the reset delays of the USBDM.
I pushed an example code (I use Codeblocks as IDE) to KL27_USBDM_Test. I intentionally also included my srec file. I is found in the build/bin/Debug-Win folder.
To further investigate the problem I wanted to read back the flash. Unfortunately neighter USBDM nor OpenSDA support that (as far as I know). So what I did was to download my srec file via OpenSDA resulting in a fast/correct startup. After that I reprogrammed the K20 to USBDM. At this time the programm still starts immediately (this also shows that USBDM does not interfere during runtime e.g. holds reset or something else even after pushing the reset button). If I in a further step start the ARM-Programmer and Verify the Flash (of corse using exactly the same srec file) I get an error telling: ''Readback of the flash contents does not agree with buffer''. which would indicate that in deed there is something odd in the flash.
I also should mention, that I returned to my FRDM-Board to investigate that problem (therefore also the example code is written for the FRDM-Board. It just lets the green led flash). As all FRDM-Boards are labeled with the revision I thought it might be of help telling my version. The label says: 700-28303 REV A and SCH-28303 REV B.
Please let me know if I can do anything else to support finding this oddity.
Thanks.

[podonoghue]

Hi Roman,

I apologize - I have read your posting several times and for some reason I still thought you were using a KL25.

With the KL27 it is necessary to program the Bootloader options correctly. USBDM by default uses the erase default of 0xFF. It is likely that the OpenSDA is using a different default.

You are experiencing the bootloader delay waiting for a connection on the I2C, serial etc. before running the flash code.

The bootloader options are controlled by the FOPT byte in the security region. See Section 6.3.2 in the device manual.

You should be able change these options on the Advanced page of the programmer as part of the Security options, however, at the moment, there seems to be a bug preventing this. I don't know when this appeared as it is not an option I use.

Your project should set the FOPT byte appropriately in the image being produced for programming.
I believe it is unwise to assume (any) programmer will do the right thing by default since the correct option depends on the programmer's intentions.

A further complication is that changes in FOPT bootloader options only have effect on a Power-on reset so this will produce confusing results i.e. You can change the FOPT but it will have no apparent effect.

After doing this when using the USBDM programmer you should choose the Image option for security to ensure that no modification of the security data in the image occurs.

I have attached an example project that does this in KDS. Have a look at the vectors.c file.
frdm-kl27.zip

Using the Image option with the code you provided also works but you may need to do a power cycle to make sure the new FOPT value has been applied.

bye

PS. There is a bug in the current programmer were it may fail to verify due to inconsistencies in how the security region is handled for the "smart" case when doing the read-back verify.

bye

[RGassmann]

Hi pgo,

thanks for looking in to this. Your answer cleares most of my problems.
I'm a bit frustrated as I thought that this might be caused by the
bootloader from the beginning. I even changed the FOPT byte in the security region.
This lead to some changes of the NMI-pin
behavior therefore I thought that the FOPT byte was programmed successfully.
But as the boot delay was still present. I started to check other things.

Well at the end it was the Image option for security
(which is set to unsecure as default in my terminalcommand). As soon as I
changed that to Image as you suggested, everything worked fine, and even my
changes to the FOPT byte results in different bootsequences and not only the NMI-pin :-).

As for the future it would be great to have the possibility to read back the flash of the uC
in order to check what really is programmed. This way I think I could have figured that out much earlier.
Do you think it is possible to include that option in a future release?

Well again thanks for your support.

Greetings
Roman

[podonoghue]

Hi Roman,

There is a separate utility to read back from the target. USBDMMemoryDump.
This can be used to save an image of a target for comparison if you wish.

bye