Support flashing OpenMote via serial interface with 'make flash'

[aeneby]

Support flashing openmote-cc2538 board via cc2538-bsl script directly from Makefile target 'flash', and make this the default flashing method for this platform.

Fixes issue #4434.

TODO: Update wiki, which currently suggests that only JTAG flashing is supported.

[aeneby]

Note that PR #4433 should also be considered with this PR, since otherwise flashing an image via this method will probably lock the user out of the bootloader, and JTAG flashing will be their only option.

[thomaseichinger]

@aeneby Great, thanks a lot. I suggest we take care of #4433 first. I won't be able to test this for the next two weeks, therefor I reassign.

[haukepetersen]

gave this a quick try, but did not succeed.

I did merge this PR ans well as #4433 on top of master. Then I merged in also #4937 (as my JLink adapter was having trouble with the existing Jlink scripts...). Then I did flash using JTAG once successfully, but afterwards I was still not able to flash using bsl... Any ideas?

[aeneby]

@haukepetersen did you boot the MCU into the bootloader before trying to flash with bsl? With these patches, this is done by connecting the ON/SLEEP and GND pins and power-cycling the board. When the onboard bootloader is booted (rather than whatever is in flash), all 4 leds on the OpenMote should glow faintly together, and the bsl script should Just Work.

If you already did this, what was the error you got?

[haukepetersen]

no, this I did not do... I will give it another try

[aeneby]

Rebased to master after inclusion of #4937. A few notes, since it's been a while since I played around with this and things have changed since then:

• Just to clarify, for consistency this probably needs to be tested with Update OpenMote board header file to define UPDATE_CCA #4433 included. This is because Update OpenMote board header file to define UPDATE_CCA #4433 updates the CCA's "valid image" bit to true on a successful flash, and also allows it to be re-set to false by grounding ON/SLEEP during boot as described above (and therefore activating the bootloader, allowing flashing via the bsl script). Without Update OpenMote board header file to define UPDATE_CCA #4433 it's possible to end up in a configuration where the "valid image" bit is always set to false, or always true, each with their own set of confusing problems when trying to test things.
• With this PR, "make flash" using the bsl script fails. This seems to be because the makefile attempts to flash a .hex file which is too big for the flash (at least with the "default" example program), and the script throws some weird error about "unhashable type: "list"". I have no idea why this is but it wasn't the case before. Any ideas?
• Flashing with BOARD=openmote-cc2538 PROGRAMMER=jlink make flash works, because this target seems to create a .bin file with the correct size. This is then flashed by the jlink programmer and everything is fine. Flashing with the bsl script once this .bin file exists succeeds, but to create it it seems you need to flash with the jlink first?

[kYc0o]

Can you rebase this since #4433 was merged? this way I can test this too

[aeneby]

Rebased. Thanks @kYc0o

[kYc0o]

I tested this and I can confirm that it works but actually, as @aeneby says we need to generate this .bin file.
I think we can try to generate it using the JLink script and then flash the .bin file.
Can you do this?

[aeneby]

Okay the problem was that #4937 changed the output format from binary to ihex, so I've modified the Makefile to fix this by setting the HEXFILE and OFLAGS variables when flashing via the bsl script. @kYc0o can you test again?

[kYc0o]

Ok it's working now, but it's quite slow... any reason to keep the baudrate at 115200?

[aeneby]

Well spotted. No, there's no reason it needs to be 115200.

According to the documentation, the cc2538 supports up to 460800 baud, which may be doubled using an external clock. Looking at the script, it should actually negotiate this double-speed automatically if you don't specify a baud rate, but for me doing this fails:

Connecting to target...
*** sending synch sequence
*** SetXOsc command (0x29)
Target replied with a NACK during SetXOsc (0x29)
ERROR: Can't switch target to external clock source. (Try forcing speed)

So I've updated the baud rate to 460800.

[kYc0o]

Humm... it's strange but the flashing time is still the same even at a high baudrate. I wonder why the cc2538dk using the same script and almost the same parameters can flash much faster.
Anyways, this is working for now and improvements for speed can be done in another PR.
ACK and launch CI tools.

[kYc0o]

Let's flash them all! Go!

[aeneby]

Thanks @kYc0o :)

For the record though, I did notice an increase in speed with the changed baud rate. From ~70s to ~30s for the flashing process. Strange that you didn't see the same result.