topic Re: USBDM software problems with Kinetis E targets in OSBDM and TBDML

USBDM software problems with Kinetis E targets

raimonddragomir — Sun, 05 Mar 2017 13:04:38 GMT

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

Re: USBDM software problems with Kinetis E targets

pgo — Tue, 07 Mar 2017 11:34:25 GMT

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

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Tue, 07 Mar 2017 14:02:48 GMT

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>

Re: USBDM software problems with Kinetis E targets

pgo — Wed, 08 Mar 2017 09:18:39 GMT

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

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Wed, 08 Mar 2017 09:42:39 GMT

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>

Re: USBDM software problems with Kinetis E targets

pgo — Wed, 22 Mar 2017 09:15:21 GMT

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

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Wed, 22 Mar 2017 11:36:26 GMT

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

Re: USBDM software problems with Kinetis E targets

pgo — Thu, 23 Mar 2017 22:19:43 GMT

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

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Fri, 24 Mar 2017 05:56:35 GMT

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>

Re: USBDM software problems with Kinetis E targets

pgo — Fri, 24 Mar 2017 06:54:44 GMT

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

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Fri, 24 Mar 2017 07:27:12 GMT

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>

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Sun, 26 Mar 2017 09:57:19 GMT

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>

Re: USBDM software problems with Kinetis E targets

pgo — Wed, 12 Apr 2017 12:03:01 GMT

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

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Wed, 12 Apr 2017 12:55:31 GMT

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>

Re: USBDM software problems with Kinetis E targets

pgo — Fri, 14 Apr 2017 03:25:00 GMT

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

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Fri, 14 Apr 2017 05:39:59 GMT

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>

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Fri, 14 Apr 2017 05:44:11 GMT

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>

Re: USBDM software problems with Kinetis E targets

pgo — Fri, 14 Apr 2017 06:19:23 GMT

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.

Re: USBDM software problems with Kinetis E targets

raimonddragomir — Fri, 14 Apr 2017 07:56:12 GMT

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>

Re: USBDM software problems with Kinetis E targets

pgo — Fri, 14 Apr 2017 11:41:58 GMT

Hi Raimond,

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

bye