[SOLVED] J-Flasher: #select and *.ini file problem

GrzesiekG · Aug 12th 2015, 1:01pm

Hello,

I'm working on a production/test bench for our company. We need to program two ICs on one PCB. We want to use relays to switch the target for the SWD interface. Also we need to use the #select command (using the RS-232 interface). So I'm preparing the two pairs of *.cfg and *.dat files, booting the Flasher into MSD mode and upload those. Also I write the FLASHER.INI file, just like in the manual.
The problem is that, when I use the #select command, the flasher responds with ACK, but when I invoke #auto, the flasher responds with an error255: public:0:\FLASHER2.CFG, where FLASHER2 is what I've selected. Next, when I check the *.ini file in the MSD mode again, it seems to be updated to the path "public:0:\FLASHER2.CFG" and so on. What is going on?

Please help

SEGGER - Erik · Aug 12th 2015, 3:16pm

Hello,

What version of the J-Link software are you using? We have fixed this behavior in V5.00l of the J-Link software.
Can you please give it a try? Download-Link: segger.com/jlink-software.html

- Erik

GrzesiekG · Aug 12th 2015, 4:54pm

I downloaded and installed that version yesterday and thought that the installation wizzard would upgrade my last version (4.8 or something like that). Unfortunatelly, after the installation, my Win8.1 called the older version through the shortcuts

I've deleted all and installed the v5.0. It works now

The other thing is that I'm using only SWCLK and SWDIO (no nRST). After calling the #start command my device (STM32F411VE) doesn't start (I need to power cycle it). While using J-Flash (and the flasher) I only have to hold down the reset button on my custom PCB (if not, it shows some errors about Program Counter value or RAM access violation). Whilst flashing an STM32F103 I didn't have to do anything. Do you know why it is happening?

SEGGER - Erik · Aug 12th 2015, 5:05pm

Thank you for confirmation that the new version solves the issue

Regarding #start command:

Do you know why it is happening?

As you have already noticed, currently J-Flash and Flasher stand-alone mode does not perform the same action to start the application. J-Flash tries to start the application by setting reset bits through the debug interface of the core while the Flasher toggles the reset pin. The proper way of starting the application is the way used by Flasher in stand-alone mode (reset pin) as forcing a reset through the debug interface does not work for all CPUs. We have this already on our internal todo to change the start application sequence in J-Flash to the one used by Flasher.

We always recommend to connect the nRST pin in order to allow Flasher / J-Flash to perform a reset in order to start the application. Furthermore, this allows the Flasher to perform a connect under reset in case of a "bad" application has been programmed into the flash.

Share