[SOLVED] Flasher portable standalone issue

Davor EMS · May 2nd 2017, 9:34am

Hi,
I have an issue with the Flasher Portable: I'm not able to use it in standalone mode, but it works well while connected to a PC. Hereafter the error:
ERROR: Failed to download RAMCode.
ERROR: Failed to prepare for programming.
Failed to download RAMCode!
SN: 1 – Failed

Environment info:

Win 7 professional
J-Flash 6.14d (also tried v6.15c)
Flasher Portable
Target Cortex-M0 MKL16Z128VLH4R

I've tried to configure the project in order to perform only programming operation (no erase, nor verify). But this doesn't solve the issue.
Anyone can help please?

Thanks in advance.

SEGGER - Niklas · May 2nd 2017, 9:51am

Hi,

could you please try to disable the watchdog of the device in the init steps of J-Flash and see if this works for you?
An example(for the MK24xx) can be found here:

[SOLVED] Flasher Portable MK24FN Ram Check Failure

Best regards,
Niklas

Davor EMS · May 2nd 2017, 11:38am

Hi Niklas,
thanks for your answer. I understand what you are asking for but I find difficult to implement it.

To disable the watchdog I shall reset COP control register (bit 2 and 3), how I can find more informations about how to do it in "Init steps"?

Thanks in advance and regards,
Davor

Davor EMS · May 2nd 2017, 12:44pm

Hi Niklas,
I've implemented something that seems to work better, see attached project. However I'm able to use the flasher in standalone mode only if the chip is already erased. We work in security mode and a mass erase is necessary to reprogram the chip.

Any suggestions please?

Thanks,
Davor

SEGGER - Niklas · May 2nd 2017, 3:15pm

Hi Davor,

do I understand you correctly that the devices you want to program come into production with security enabled and therefore need to be unlocked & mass-erased?

Best regards,
Niklas

Davor EMS · May 2nd 2017, 3:19pm

Niklas,
yes. The devices are already programmed and we need to rework lots of them with a new SW release. Unlock and erase are needed in order to be able to program them again.

Sincerely,
Davor

SEGGER - Niklas · May 2nd 2017, 3:52pm

Hi Davor,

I just gave it a try on a FRDM-KL26Z:
Standalone programming a unsecured device works. (Therefore any workaround regarding the watchdog seems unnecessary)
Standalone programming a secured device (0x040C set to 0xFF) also works.

Could you please provide us with more information on how the devices are secured?

Best regards,
Niklas

Davor EMS · May 2nd 2017, 5:30pm

Hi Niklas,
actually you are right: with unsecured device I'm able to program in standalone mode even without "Init steps" WDG disabling.

We secure the chip by setting 0x040C to 0xF4. By this we disable freescale factory access and we secure the flash. In this case I'm not able to program the chip in standalone mode... for now with or without WDG disabling instructions.

Regards,
Davor

SEGGER - Niklas · May 2nd 2017, 6:37pm

Hi Davor,

I will give this a try tomorrow.

Best regards,
Niklas

Davor EMS · May 3rd 2017, 10:34am

Hi Niklas,
Yesterday after reading your post

[...] Standalone programming a secured device (0x040C set to 0xFF) also works. [...]

I start wondering if secured device was the issue, so this morning I made some test. Result is that Flasher portable seems to work with 0x040C set to 0xF7. Freescale datasheet says that 01b is unsecured and others combination are always secured and we choose 00b.

Can you check if I'm right please?

Due to the fact that we develop medical devices it would be nice to avoid a new SW release: that's lots of documentation and validations. Can you provide a way to make it works with our bit configuration?

Thanks in advance.
Regards,
Davor

SEGGER - Niklas · May 3rd 2017, 11:42am

Hi Davor,

I tested stand-alone with 0x40C set to 0xF4 and 0xF7 and both worked fine (like 0xFF and 0xFE).

Therefore, I can not reproduce any issue regarding stand-alone programming, regardless of the setting of the option bytes.
Could you please check that the issue is not caused by the target application by programming test data with option bytes set to 0xF4 (which is what you use in production)?
If it is reproducible with test data, could you please provide us with the data file? (which should not be an issue, as it only contains test data).

Best regards,
Niklas

Davor EMS · May 3rd 2017, 2:52pm

Hi Niklas,
thanks for your feedback. I'll try ASAP the test you describe.

Sincerely,
Davor

SEGGER - Niklas · May 4th 2017, 2:05pm

Hi Davor,

just got an input from my colleagues:

Could you please check if the reset pin is connected to the MCU on the target side on the product?

Best regards,
Niklas

Davor EMS · May 9th 2017, 11:41am

Hi Niklas,
actually the Flasher Portable stop working. So I was wondering if the cable could be the issue source... we are checking it right now. A scheme would be highly appreciated.

Thanks in advance,
Davor

PS: if this doesn't work we should try with a test SW. We just received 5 new Flasher Portable and we are stucked.

Davor EMS · May 9th 2017, 3:40pm

Dear Niklas,
it works again but I cannot say why yet.

I tried the JFlash 6.15c beta and I copied in the Flasher also the directory with the Connect.pex file.

Now my colleague will try to find an official procedure in order to document it. In anycase one of these two variations is the solution.

Hope this helps someone.

Cheers,
Davor

Davor EMS · May 10th 2017, 10:40am

It seems that copying also the Connect.pex file stored in the %config directory is the solution. No matter which version of JFlash is used.

SEGGER - Niklas · May 10th 2017, 10:51am

Hi Davor,

Thanks for the feedback. Good to hear that everything works for you now

Do I understand you correctly that the issue was caused by not downloading via the "Download config & data file to flasher" option but creating the required files via the "Save Flasher config file" and "Save Flasher data file" option and not copying the *.pex file to the Flasher?

Best regards,
Niklas

Share