USBDM software problems with Kinetis E targets

[raimonddragomir]

I'm using USBDM only for Kinetis E targets. I started with KE02Z microcontrollers and was using .120 version for quite a while. Recently I started using the more advanced KE1xF familiy (cortex-m4) and installed .150 and then .160 just to see if there is support for it (unfortunately... not... yet).

The thing is that when I came back to my KE02Z devices nothing worked reliable. In fact the only thing working seems to be mass erase... I downgraded back to .150 - no luck. I downgraded again to .120 - Voila!

So the .120 works just fine with KE02Z devices, the 150/160 seems not.

I'm using a JS16 based dongle. Not tried with an OpenSDA one. For my KE1xF devices I'm using indeed a FRDM board for KE1xZ (because they have the same support for 5V devices like the TWR18F boards) and an opensda version for segger j-link :smileyalert: It's just a shame that the open source opensda firmware for these devices is not yet functional :smileysad:

I hope I will see KE1xF support for USBDM soon!

Also, a very interesting feature would be a possibility to partition the FlexNVM system for using as eeprom. The chips come with the FlexNVM factory default as all dataflash, and if you really  want to use it as eeprom you need to run first a small application which configures it as such. Besides developing such an application, this implies another step in production programming.

Best regards,

Raimond

[pgo]

Hi Raimond,

I am very busy at the moment and don't have time to do much investigation but I did the following tests with the stand-alone programmer:

• FRDM-KE02Z40M board using the on-board programming hardware
• FRDM-KE02Z board using the on-board programming hardware
• FRDM-KE15Z board using the on-board programming hardware
• Minimal S9KEAZN8 with JS16 programmer

• Minimal S9KEAZN64 with JS16 programmer

They all programmed correctly with a synthetic test file that fully occupies the flash.  This was with version 4.12.1.160.

Did you update the BDM firmware when you tried the later versions of USBDM?

I will do a more thorough check when I have time.

I don't have access to a MK1xF device which is why it is not supported.

bye

[raimonddragomir]

Hi pgo,

It doesn't seem the JS16 firmware is changed from 120 to 160. Is it? I'm

using a JS16 hardware.

I really don't remember if the usbdm on my FRDM boards worked or not with

KE02Z devices. I tried my FRDM-KE15Z to make it work with a KE14F256 target

with no luck. As I said, it even didn't work with the "official" opensda

distribution (and found on some forum that this is true, and the only

chance is a segger j-link firmware/software...)

So the combination that seems not to work is 150b/160 software with JS16

programming dongle for Kinetis E targets...

Best regards,

Raimond

2017-03-07 13:35 GMT+02:00 pgo <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: USBDM software problems with Kinetis E targets

reply from pgo

<https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

and TBDML* - View the full discussion

<https://community.nxp.com/message/884391?commentID=884391&et=watches.email.thread#comment-884391>

[pgo]

Hi Raimond,

Can you provide the exact part number of the device you find the programming fails on?

The circuit might also be useful.

thanks

[raimonddragomir]

Hi pgo,

what failed was an MKE02Z16VLD2 and an MKE02Z64VLD2 (16K and 64K otherwise

the same chip).

One of them has NMI as output, but it's driving a load that has a 13K

equivalent resistance to GND. The other one is an input (the MISO pin at a

SPI port). That one receives the output of a SPI device.

I also disable the NMI in my firmwares. This NMI thing is annoying, I don't

know why this NMI thing gets in the 21st century microcontrollers...

BTW, I found an issue o these 5V micros: On some of my 5V designs, I setup

the LVD trip point to 4.3V. Later, I made a design with the same chip (an

MKE02Z16VLC2) but at 3.3V, and forgot the LVD trip point to 4.3V. Result:

the chip never came up from reset (or if it did it was for a very short

time - in fact it must be it, because that setting of the LVD was in my

application). Also, the reset line was kept as an output low - I found this

because when I tried an opensda dongle it turned up in bootloader mode!

The solution was to cut the 3.3V trace from the chip - I was lucky about it

because it was simple enough) and to connect a 5V to it. The chip started

normally and I was able to reprogram it.

So, it is a possibility of "bricking" a device like this. But I'm thinking,

because the application is really starting for a moment, is this a

possibility to unbrick the chip with USBDM? A solution would be that the

USBDM to connect to the chip under reset. But this seems that it is not

working, and I don't understand why. My command line is:

"C:\Program Files\pgo\USBDM 4.12.1.150\UsbdmFlashProgrammer.exe"

-device=MKE02Z16M2 -useReset -erase=mass -program -execute a.axf

and I understand that "useReset" is the flag that tells it to connect to

the chip under reset. Is it correct?

Thanks,

Raimond

2017-03-08 11:19 GMT+02:00 pgo <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: USBDM software problems with Kinetis E targets

reply from pgo

<https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

and TBDML* - View the full discussion

<https://community.nxp.com/message/884702?commentID=884702&et=watches.email.thread#comment-884702>

[pgo]

Hi Raimond,

I suspect it is the NMI that is upsetting the programming.

I have ordered a MKE02Z16VLD2 and will build a minimal prototype for testing but this will not occur for a while.

The NMI can't (normally) be disabled in by the USBDM programming since once disabled it cannot be enabled except by a power-on reset I believe,

bye

[raimonddragomir]

>

The NMI can't (normally) be disabled in by the USBDM programming since

once disabled it cannot be enabled except by a power-on reset I believe,

>

I don't think so, the NMI and RESET enabling bits are write-once, but

after ANY reset. So as long as you reset the chip after programming, it

should work. I didn't test that, but you can test it when you'll work on it.

Regarding this, the KE1x family is improved anyway, because the NMI and

RESET pins can be enabled/disabled in the FOPT.

Best regards,

Raimond

[pgo]

Hi Raymond,

you are correct which leaves me puzzled since I checked that before posting.  I must have looked at the wrong data sheet :smileyhappy: 

It is still a problem since the FOPT_NMI is unaffected by normal resets so the programmer would have to restore the value which would be an issue as it would lock the value.  The only approach would be to restore the value and then  do a reset to unlock it.  There isn't provision to do this in the debug sequence but it could be done for general programming where it wouldn't matter - except they share the same code.  I will have to think if this is practical.

Basically the NMI pin is a pain.

bye

[raimonddragomir]

I agree :smileyhappy:

Because the KE0x family is different from KE1x I would see two different

approaches:

KE0x:

1 disable NMI

2 do programming

3 reset

4 enable NMI

5 reset

KE1x:

1 disable NMI: PORTD->PCR[3] = 0x100; // ALT1=gpio

2 do programming

3 enable NMI: PORTD->PCR[3] = 0x703; // ALT7=NMI, pull-up enable

KE1x is simpler, no write-once bits, FOPT option...

You are right, FOPT is loaded only on POR, but there is no problem to

restore the NMI settings in code.

Best regards,

Raimond

2017-03-24 0:20 GMT+02:00 pgo <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: USBDM software problems with Kinetis E targets

reply from pgo

<https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

and TBDML* - View the full discussion

<https://community.nxp.com/message/890259?commentID=890259&et=watches.email.thread#comment-890259>

[pgo]

Hi Raymond,

 I have restored the old behaviour of disabling NMI for the MKE devices but it doesn't currently re-enable as there isn't a convenient point in the programming sequence to do it.  I don't want to modify the software - just the TCL scripts.  I will have to look at this more carefully but I will probably wait until I have a minimum chip on a proto-board. 

The idea of disabling the pin function on the MK1x devices is interesting but I haven't thought it through.

In any case I have just uploaded V12.160 to sourceforge which I would appreciate you testing and see if this is actually an issue with the NMI as suspected.

If you want to play with this yourself you can try modifying the TCL scripts and possible the ARM devices XML.  Note that you would have to run the programmer directly from the executable as the Windows shortcut will automatically restore the old files!

bye

[raimonddragomir]

Hi pgo,

Didn't have much time, but I do tested on one board with a MKE02Z64VLD2

(NMI used as SPI_MISO).

160 version is able to autodetect the chip, but it fail to mass-erase

and/or load the file with the following message:

(the same reason for mass-erase - this seems to be new, I remember

mass-erase working...)

using 120 version still works like a charm.... :smileyhappy:

My firmware does nothing special about the reset, nmi and swd pins, except

disabling the nmi pin very shortly after reset. reset and swd pins are not

touched.

As a side remark, I am very happy about 120 version, which works very well

with my KE02 chips. I only switched to newer versions to see if they

support the KE1xF (the cortex-m4 F series, not Z series).

I would keep an eye of the USBD development in this regard. I'm forced to

use a FRDM-KE15Z board with a segger j-link firmware for programming them

(this FRDM board because it has good 3V-5V target support in hardware).

Although I also tested the internal bootloader on these chips with good

success, it's hard to make my mind in choosing SWD or the bootloader. There

are FOPT values that can brick the chip if using only the bootloader

option...

Best regards,

Raimond

2017-03-24 9:26 GMT+02:00 Raimond Dragomir <raimond.dragomir@gmail.com>:

Thanks pgo,

I will play with it a bit in the weekend.

>

2017-03-24 8:55 GMT+02:00 pgo <admin@community.nxp.com>:

>> NXP Community

>> <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

>> Re: USBDM software problems with Kinetis E targets

>>

>> reply from pgo

>> <https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

>> and TBDML* - View the full discussion

>> <https://community.nxp.com/message/890383?commentID=890383&et=watches.email.thread#comment-890383>

>>

[pgo]

Hi Raymond,

It has taken a while to get back to this.

I have just built a minimal MKE02Z64VLD2 board to test with.

I have located a problem in the C:\Program Files (x86)\pgo\USBDM 4.12.1.160\DeviceData\ARM\Kinetis-KExx-flash-scripts.tcl script used for the MKE02 chips.

I have attached the fixed file if you feel inclined to try it.  It should work with whatever version of USBDM is installed and work irrespective of the NMI pin.

bye

[raimonddragomir]

I responded to the wrong thread...

Here it is again

Hi pgo,

Sorry to dissapoint you, but it's still not working. Something happens just

at the end of flash programming (I can see the progress because it's a ~16K

binary). Then it fails with this message:

(Programming of the target flash failed! Reason: Internal program error -

please report).

The interesting thing is that the programmed binary is almost working! Only

that it's resetting itself after probably one second. I saw this easily on

my board because I have a flashing led pattern in the first 200ms in my

application.

I also installed 140 version (I had 120) and I can confirm it's working.

Now I have the 140 and 160 versions on my computer. 140 is working well,

160 fails in this new way.

The chip is a MKE02Z64VLD2.

2017-04-12 15:03 GMT+03:00 pgo <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: USBDM software problems with Kinetis E targets

reply from pgo

<https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

and TBDML* - View the full discussion

<https://community.nxp.com/message/896258?commentID=896258&et=watches.email.thread#comment-896258>

[pgo]

Hi Raimond,

Sorry to hear that! Thanks for your patience.

I will probably upload V4.12.1.170 anyway, as it has some other bug fixes.

The device tested was a MKE02Z64VLD2 with the following very minimal circuit:

The test file was a random data image 64K flash+256 byes eeprom.

Testing was done with a MK22F and a JS16-SWD version of USBDM hardware.

Tested with NMI open and pulled low.

This testing was done with the stand-alone programmer.

Can you upload you test program please and I will see if it behaves differently.

It is also possible that some other changes in V4.12.1.170 affect things I suppose.

bye

[raimonddragomir]

Connect the leds in sinking mode like this (I noticed you put your leds in

sourcing mode):

2017-04-14 8:39 GMT+03:00 Raimond Dragomir <raimond.dragomir@gmail.com>:

Hi pgo

Here it is the cpu. It doesn't use an external crystal. Just after reset

it toggles the LED1...LED4 in sequence, 50ms per led.

I've also attached the elf file, so you can load it.

here it is the startup:

NAKED void Reset_Handler()

{

DI();

// disable watchdog as early as possible, but set the update bit

// to allow the application to enable it later.

WDOG_UNLOCK();

// the following write sequence must be completed within 128 bus clocks

WDOG->CS2 = 0;

WDOG->TOVAL = 0xFFFF;

WDOG->WIN = 0;

WDOG->CS1 = 0x20; // update bit set

// Disale NMI pin function, keep RESET and SWD pins

SIM->SOPT &= ~SIM_SOPT_NMIE_MASK;

extern uint32_t _etext, _data, _edata, _bss, _ebss;

uint32_t *src = &_etext;

uint32_t *dst = &_data;

while (dst < &_edata) *dst++ = *src++;

for (dst = &_bss; dst < &_ebss; dst++) *dst = 0;

main();

}

void Default_Handler()

{

while (1) {}

}

void NMI_Handler()

{

}

I think the only other important thing in the sources is that after

exactly one second from reset I disable the SWD pins and enable the FTM1

and GPIO on them for an emulated UART for debugging. Although I don't know

if it is a problem because the SWD pins can be enabled/disabled at will,

they aren't write once like the NMI and reset pins.

Hope this help. If you connect at your board the leds on the pins used in

my schematic, you should see them light only once after reset for a good

program. As I said, when programmed with the current 160 with the patched

script, I can see them light repeatdly, the sign that there is a reset at

some point.

>

2017-04-14 6:26 GMT+03:00 pgo <admin@community.nxp.com>:

>> NXP Community

>> <https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

>> Re: USBDM software problems with Kinetis E targets

>>

>> reply from pgo

>> <https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

>> and TBDML* - View the full discussion

>> <https://community.nxp.com/message/896889?commentID=896889&et=watches.email.thread#comment-896889>

>>

[pgo]

Hi Raimond,

The image file appears to contain data intended for RAM.  The programmer  is choking on that:

    doFlashBlock(): op=OpWriteRam, [0x1FFFFC00..0x1FFFFC2F]
    doFlashBlock(): Processing RAM[0x1FFFFC00..0x1FFFFC2F]
       loadTargetProgram(): Failed, no flash program found for target

It is unusual to have RAM in an image intended for programming but the programmer should still write the data to RAM -  It appears to be confused and is looking for a programming algorithm that applies to that range of memory.

RAM processing is done as a second pass after the Flash programming.  This means that the Flash has actually been successfully programmed.

I'll look at the reason for the failure.  It may be that the ELF loading code is incorrectly assuming the RAM block needs to be loaded.

I would also suggest you check your map file and linker file to see where the RAM data is coming from.  The segment may be incorrectly configured.

Either way it should not fail in this fashion.

bye

PS.

OK - fixed (I hope) in the version being uploaded.

As a further note: Images containing RAM data may fail verify as the RAM data is (of course) volatile.

[raimonddragomir]

Weird. See the files attached. From what I can see the ram implied is from

the .data segment, the load address being 0x03C90 in flash.

I may suspect that your program loaded the flash only until the 0x03C90 and

the last 0x30 bytes directly in RAM... And my application just doesn't have

the data at 0x03C90 at runtime...

2017-04-14 9:19 GMT+03:00 pgo <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: USBDM software problems with Kinetis E targets

reply from pgo

<https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

and TBDML* - View the full discussion

<https://community.nxp.com/message/896895?commentID=896895&et=watches.email.thread#comment-896895>

[pgo]

Hi Raimond,

Version 4.12.1.170 uses a different method for loading ELF files which should operate correctly,

bye

[raimonddragomir]

It's working, thanks!

The GUI version has some problems, but the command line works well.

I also tested the "MKE18". I had to modify a bit the xml because I have the

MKE14F variant (not MKE18F, not MKE16F) which wasn't recognized by the

id/mask. Once recognized it works.

About the naming, there is a little bit unfortunate naming of the last two

families:

There is the KE1xZ family (m0+) with:

MKE14Z

MKE15Z

And there is the KE1xF familiy (m4) with:

MKE14F

MKE16F

MKE18F

Probably "MKE15" and "MKE18" are good names for the families, but the MKE14

name is clashing... I mean, when you have an MKE14Z chip you should choose

"MKE15" familiy, and when you have an MKE14F chip you should choose "MKE18"

:smileyhappy:

Best regards,

Raimond

2017-04-14 14:42 GMT+03:00 pgo <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: USBDM software problems with Kinetis E targets

reply from pgo

<https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

and TBDML* - View the full discussion

<https://community.nxp.com/message/897051?commentID=897051&et=watches.email.thread#comment-897051>

[pgo]

Hi Raimond,

I will update the MKE hierarchy as follows in the next version:

MKE02Z2
   MKE02Z16M2
   MKE02Z32M2
   MKE02Z64M2
MKE02Z4
   MKE02Z16M4
MKE04Z4
   MKE04Z8M4
   MKE04Z64M4
   MKE04Z128M4
MKE06Z4
   MKE06Z64M4
   MKE06Z128M4
MKE1xZ7
   MKE14Z128M7
   MKE14Z256M7
   MKE15Z128M7
   MKE15Z256M7
MKE1xF16
   MKE14F256M16
   MKE14F512M16
   MKE16F256M16
   MKE16F512M16
   MKE18F256M16
   MKE18F512M16

This should be more consistent.

Most of the MKE1xZ7 and MKE1xF16 devices will probably be aliases as they only differ in some peripherals.

bye

[raimonddragomir]

Hi pgo

Here it is the cpu. It doesn't use an external crystal. Just after reset it

toggles the LED1...LED4 in sequence, 50ms per led.

I've also attached the elf file, so you can load it.

here it is the startup:

NAKED void Reset_Handler()

{

DI();

// disable watchdog as early as possible, but set the update bit

// to allow the application to enable it later.

WDOG_UNLOCK();

// the following write sequence must be completed within 128 bus clocks

WDOG->CS2 = 0;

WDOG->TOVAL = 0xFFFF;

WDOG->WIN = 0;

WDOG->CS1 = 0x20; // update bit set

// Disale NMI pin function, keep RESET and SWD pins

SIM->SOPT &= ~SIM_SOPT_NMIE_MASK;

extern uint32_t _etext, _data, _edata, _bss, _ebss;

uint32_t *src = &_etext;

uint32_t *dst = &_data;

while (dst < &_edata) *dst++ = *src++;

for (dst = &_bss; dst < &_ebss; dst++) *dst = 0;

main();

}

void Default_Handler()

{

while (1) {}

}

void NMI_Handler()

{

}

I think the only other important thing in the sources is that after exactly

one second from reset I disable the SWD pins and enable the FTM1 and GPIO

on them for an emulated UART for debugging. Although I don't know if it is

a problem because the SWD pins can be enabled/disabled at will, they aren't

write once like the NMI and reset pins.

Hope this help. If you connect at your board the leds on the pins used in

my schematic, you should see them light only once after reset for a good

program. As I said, when programmed with the current 160 with the patched

script, I can see them light repeatdly, the sign that there is a reset at

some point.

2017-04-14 6:26 GMT+03:00 pgo <admin@community.nxp.com>:

NXP Community

<https://community.freescale.com/resources/statics/1000/35400-NXP-Community-Email-banner-600x75.jpg>

Re: USBDM software problems with Kinetis E targets

reply from pgo

<https://community.nxp.com/people/pgo?et=watches.email.thread> in *OSBDM

and TBDML* - View the full discussion

<https://community.nxp.com/message/896889?commentID=896889&et=watches.email.thread#comment-896889>