Cool! Unfortunately I don't have a re-mote with JTAG header at hand. Personally I find it a bit confusing to have two default tools, defendant on what you do. Further, we won't need the newly introduced variable. I would go with cc2538-bsl as default.

Unfortunately I don't have a re-mote with JTAG header at hand.

me neither, also I don't like to have JLINK reseter the default as it requires the JTAG header which is not on any remote by default.

The requirements for the usage of the target reset are mostly used in RIOT for testing purposes. Currently, make test doesn't work at all, and according to my tests it's related to the fact that the cc2538-bsl.py script is triggered by make reset while a make term is done, which of course conflicts. There might be a chance in 100 that you'd be able to talk to the serial line with the script, but that's not reliable at all. Moreover, in a "desk" test you are able to press the reset button if needed.

The logic behind this PR is that murdock can run make flash-only test on a worker to perform a test, and since we cannot pass variables to the worker (e.g. RESETER=jlink) we need to set jlink as the default reseter. I added such a variable in case of anyone, even if almost useless, wants to perform make reset without a jlink debugger.

For background purposes: we are trying to find a solution to accommodate the ReMote in the CI.
@PeterKietzmann @smlng what alternative would you propose?

The purpose is fully clear as well as the usefulness. I didn't think about workers inability to get environmental variables. Still feels like the wrong fix but I have no alternative at hand so I won't NACK. Still needs to be tested though.

since we cannot pass variables to the worker

it sounds like we should fix that, and not setting a default which will not work for most people, ie. those with unmodified remotes. Also its a counter intuitive to have the default flasher and reset using different tools.

maybe @kaspar030 can help with the Murdock issue and explain how to pass or set ENV variables for workers.

it sounds like we should fix that, and not setting a default which will not work for most people, ie. those with unmodified remotes.

IMHO it seems quite complicated to "fix it" if there's something to fix. Let's say you send a command to the workers to flash and test for a specific board, then you need to make BOARD=your_board make flash-only test, which is kind of easy to do. But then we add complexity by saying "oh you know what, this board cannot be reseted with the default tool, lets use RESETER=jlink when BOARD=remote-revb is used". I think this would be a pain. However, it might be true that we don't do this for the rest of the boards, but still, it opens a path to complexity.

Also its a counter intuitive to have the default flasher and reset using different tools.

I see the things like this: remote-revb didn't have a functional reset target since it was added to RIOT, nobody complained about it. A need raises which requires this reset functional, thus I added this functionality with the hope that it would solve the problem, but it didn't, though the functionality seemed nice and it stayed. Now I change the functionality to another default because that solves the problem for what I originally worked on it, and now it's counter intuitive... I agree actually, but it seems to me that this change hurts nobody and we can live with it. I should add a notice in the makefile though, to explicitly say that we can still use the script to reset the board.

@kaspar030 any opinions here?

Is this going to break someone's usecase? Seems not.
On the other hand, we could put the board untouched in our CI.
So is someone NACKing this? @kaspar030 @smlng @PeterKietzmann
Else, since this is bringing an improvement, and there are no good alternatives brought forward, how about running with that?

On my side it currently lacks testing capabilities. We have a Segger debugger but currently no cable to connect this board, stupid... I already confirmed not to NACK this PR

@kaspar030 any opinions here?

I'm still missing an analysis how exactly cc2538-bsl resets the remote, and why we cannot replicate that over serial.

I'm still missing an analysis how exactly cc2538-bsl resets the remote, and why we cannot replicate that over serial.

The cc2538-bsl communicates with the ROM bootloader embedded on the cc2538 with a specific protocol. The reset command is sent over the serial when a reboot is required, which consists in toggling RTS/DTR plus sending a command through the serial line. RTS/DTR pass through a PIC microcontroller which in turn talks with the cc2538, but I don't know the details on how, since toggling the lines performs no reset.

Now, sending the reset command while doing make term seems to have conflict since both commands use the same python script which takes over the same serial port. I didn't have any successful make test using the current reset approach.

I just tested this on a remote-reva and works as intended.
Running

PROGRAMMER=jlink BOARD=remote-reva make -C tests/shell/ flash test

performs the test.
Also BOARD=remote-reva make -C tests/shell/ reset performs the reset using JLink.

It seems that TI worked on some support for OpenOCD, see this PR and they have a fork of OpenOCD with a full support of their board. We are currently evaluating this on IoT-LAB.

With their work, there would be no need for a custom setup and a JLink debugger.

@aabadie seems like a nice feature for the future. However, I would guess that it might take a while until it gets mainline. So we don't need to obsolete this PR in favor of potential TI/OpenOCD support, right? @kaspar030 you had some open questions, do you agree with this PR now?

It seems that TI worked on some support for OpenOCD, see this PR and they have a fork of OpenOCD with a full support of their board. We are currently evaluating this on IoT-LAB.

With their work, there would be no need for a custom setup and a JLink debugger.

I was very excited when I read this. However, when I went to the link you provided I found that the support is only intended to work on cc26xx/cc13xx chips, aiming to replace the uniflash tool which is currently needed to flash such devices (cc2538-bsl was never working for those ones).

TL;DR: It doesn't work for our use case.

It doesn't work for our use case.

Yes it does, we used it on IoT-LAB. There might a commit in the git history that provides support to cc2538 but I haven't looked at it in detail.

Yes it does, we used it on IoT-LAB. There might a commit in the git history that provides support to cc2538 but I haven't looked at it in detail.

Are you sure openocd can talk BSL protocol? It seems to me very complicated since the script we're using is closely coupled with the expected commands by the embedded ROM bootloader on cc2538. Can you point me at least to the IoT-Lab branch where you're using it?

Any activity here or shall we just close?

Let's close as archived. No real progress for over a year now.