New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bossac runner flashes at an incorrect offset #33523
Comments
This board was introduced at #29097. At that time, the bossac used was nRF version as mention at #29097 (comment) @saltyJeff did you know if there is difference between the two versions: nRF vs Arduino? |
I couldn't install the arduino IDE on my linux distro for some reason, so I cloned the mainline repo and used it: It was the "nRF" branch of the "Arduino" main repository that I used to flash: https://github.com/arduino/BOSSA I assumed they were the same but something may have changed in the past few months. Can you check the hashes for the Arduino copy and the in-tree build? |
Also found this: @29312
This is listed as an undesired behavior but I believe we've hit an edge case. |
Fixed at #29874.
The #29874 introduced a lot of tests that cover many scenarios. I was wondering if someone of them not cover this. In this case, it will only require add/rem/change board definitions and it will be an easy fix. @saltyJeff , could you make me a favor? build/flash mainline using your setup. This will help us to guarantee that current mainline not changed some internal behavior around flash variables, ok? |
I'm swamped this week but if @eHammarstrom wants to try, I believe the steps are:
If not, I'll probably get around to it next week. |
I've tried to use |
Hello @eHammarstrom , As comment at BOSSAC RFC, offset indicate where erase starts. You should ensure to remove knowledge of the bootloader size from BOSSAC, see shumatech/BOSSA@dbdd088. As mentioned
This means that your bootloader/tool is not following what was defined by shumatech/BOSSA. The Zephyr west bossac follows shumatech/BOSSA#79. At end, west bossac should pass If there are something I miss, help me identify what is the proper use case to add at west bossac tests. |
@nandojve Thanks for clarifying this, I was not aware that the binaries differed in the I wonder if it would be beneficial for West's bossac runner to output a warning if a non-zephyr bossac binary is supplied? If not, you may close this ticket. |
@nandojve: The documentation here https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/arduino_nano_33_ble/doc/index.rst#programming-and-debugging says to use bossac from Arduino IDE. Is there a special Zephyr version of bossac that should be used instead? |
I'm not sure if it is possible detect. @eugmes , as far I know, @saltyJeff used a special nRF branch, see his comments here: #33523 (comment) |
Just wanted to confirm what @eugmes wrote at #33523 (comment) I was hitting the same issue when using the recommended bossac version from the documentation (arduino IDE or compiled manually). Removing the offset adding in scripts/west_commands/runners/bossac.py line 167&168 works around this for me, but there is clearly a gap between what is documented and working in Zephyr mainline. |
Can someone test the below devicetree configuration. I changed from
|
@nandojve Just checked and it does not solve the problem. Maybe the offset is still somehow being applied from west flash bossac.py runner? |
Could you execute This change on the devicetree should avoid --offset parameter because start address is 0. |
There are two solutions to this board. I think add a compatibility mode is better than change flash layout. |
Just tried with your PR and I can confirm it fixes the issue for me. I assume that means you do not want any verbose flash output anymore. If you still need any logs or such let me know. Thanks for working on this! |
Hi @Stefan-Schmidt , I'll finish PR and open to review soon. |
Part of the issue is there are two versions of BOSSA and the Arduino team have forked from the original shumatech one. The one mentioned in the nano 33 ble info is that forked version which has been redeveloped to work specifically with the nRF based boards. I expect that there will be further improvements made this version needs to be included in the west repository. |
Hi @WilliamGFish , Did you checked #34947 ? Is it working for you? |
I have applied the PR and it appears to work. The USB port on the nano 33 still doesn't seem to function. I have changed some of the switches to provide better feedback in the bossac west runner script: (scripts\west_commands\runners\bossac.py - ln 159)
and amended the Windows error check: (ln 194)
To get west to flash to flash to boards in Windows I am using: You want to roll these amendments in your PR (and give me a mention) |
Describe the bug
When flashing the arduino-nano-33-ble-sense using west the bossac runner passes --offset even though bossac seem to account for the elf offset.
This results in a "double" offset of 128kB instead of the 64kB offset where the bootloader starts execution.
To workaround this issue I can flash the device using only the bossac tool, without passing the --offset flag.
The result of the west flash is that the first 64kB of the old image
[0x10000, 0x20000]
still remain.To Reproduce
If your binaries are sub 64kB then the previous commands result in a "NOP",
if you dump flash you can see the old program at 0x10000 and the new program with a 0x20000 offset.
Expected behavior
Hello world UART output on the TX and RX pins.
Impact
Unable to flash board using west
Logs and console output
The bare bossac flash without --offset passed to it,
The west bossac flash, which is passed
-o 65536
,Environment (please complete the following information):
Linux, Debian Testing
zephyr-sdk 0.12.3
bossac "1.9.1-arduino2" shipped with the arduino IDE
zephyr v2.5-branch
The text was updated successfully, but these errors were encountered: