dlbeer
flash-bsl doesn't seem to work
The new way of doing flash-bsl doesn't work any more. If I use an older version (0.22), before the -bsl-entry-sequence feature was added, it works fine. Looking at the DTR/RTS lines with a logic analyzer shows a very strange sequence. I tried to add a custom string to see if it would act better and it only got worse. Could you try using the current version on any FRAM board and see if it works?
BTW: my configuration is the latest source code compiled Ubuntu 15.10 3.3V ft232rl ftdi dongle from sparkfun msp430fr5969 launchpad
Picture of the default bsl-entry-sequence as it looks to a logic analyzer
On Wed, Aug 31, 2016 at 08:47:12PM -0700, Rick Kimball wrote:
The new way of doing flash-bsl doesn't work any more. If I use an older version (0.22), before the -bsl-entry-sequence feature was added, it works fine. Looking at the DTR/RTS lines with a logic analyzer shows a very strange sequence. I tried to add a custom string to see if it would act better and it only got worse. Could you try using the current version on any FRAM board and see if it works?
Hi Rick,
Unfortunately I don't have suitable equipment here at the moment to test the BSL driver.
I'm guessing that the default sequence isn't working for you, but does the option you pass to bsl-entry-sequence seem to have any effect?
There have been quite a few changes to the flash-bsl driver since 0.22, and a lot of them may have affected the entry sequence. If you get time, would it be possible to do a git-bisect to narrow things down to a single commit?
Cheers, Daniel
Daniel Beer [email protected] http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
I only backed up to the old one to see if it would work after the latest version failed. I only needed the flash-bsl feature to recover an FRAM chip I had inadvertently stomped on the vector table memory. I basically wanted to let you know it seems to have problems.
$ git bisect good 520b9cd071bb27fc1b1ad38e25c5edfa8f077745 is the first bad commit commit 520b9cd071bb27fc1b1ad38e25c5edfa8f077745 Author: Daniel Beer [email protected] Date: Mon Sep 16 16:28:29 2013 +1200
flash_bsl: correct entry sequence.
Contributed by Micle Chebotarev <[email protected]>.
:040000 040000 a2f77b89df5b3d4dfbc93b3acec565b334b73efb f0e0c37f8177c31d62af6ba079a42593fa935257 M drivers
On Thu, Sep 01, 2016 at 06:53:00AM -0700, Rick Kimball wrote:
$ git bisect good 520b9cd071bb27fc1b1ad38e25c5edfa8f077745 is the first bad commit commit 520b9cd071bb27fc1b1ad38e25c5edfa8f077745 Author: Daniel Beer [email protected] Date: Mon Sep 16 16:28:29 2013 +1200
flash_bsl: correct entry sequence. Contributed by Micle Chebotarev <[email protected]>.:040000 040000 a2f77b89df5b3d4dfbc93b3acec565b334b73efb f0e0c37f8177c31d62af6ba079a42593fa935257 M drivers
Having a look at that change, I think the old sequence is:
--bsl-entry-sequence RD,r,R,r,d,R,D,r
Although I may have made a mistake. Does that option work for you?
Cheers, Daniel
Daniel Beer [email protected] http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B
Close but no cigar, and the delay compared to the original is 50ms vs 1ms
mspdebug -d /dev/ttyUSB0 --long-password --bsl-entry-sequence RD,r,R,r,d,R,D,r:DR flash-bsl
Here is a snapshot of wave form that works for me on the fram chips I've tried (msp430fr5739 and msp430fr5959) this is using the code from 0.22
On Thu, Sep 01, 2016 at 03:53:52PM -0700, Rick Kimball wrote:
Close but no cigar, and the delays from the original is 50ms vs 1ms
mspdebug -d /dev/ttyUSB0 --long-password --bsl-entry-sequence RD,r,R,r,d,R,D,r:DR flash-bsl
Ah, I have extra transitions on the end. Must have made a mistake reading the diff. How about this:
--bsl-entry-sequence RD,r,R,r,d,R
Cheers, Daniel
Daniel Beer [email protected] http://dlbeer.co.nz/ PGP: BA6E 0B26 1F89 246C E3F3 C910 1E58 C43A 160A 553B