Replies: 3 comments 6 replies
-
|
On a fresh unit, the flashloader (plus application) is programmed either via USB or via the debug interface (SWD). Theoretically the master could also be connected to each of the slaves' SPI flash chips and be able to program them that way but that's not really feasible with a standard Pico board as the SPI lines to the flash chip are not brought out to any pins or test pads. The master would also have to be able to make sure that any given slave was not actually running when programmed (or you would have two SPI masters trying to control the same chip). Even if only the master has a USB connection during normal use, I would be wary of designing a board that gave me no way at all of physically connecting to each slave (whether via USB or SWD) as there would be no (easy) way to recover a board in the event of a software problem. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks Richard.
1. I plan to use a custom board so my question is actually about RP2040.
How would the master program the slave's flash? Do I need to add some
multiplexer that will disconnect the slave from the flash while programming.
2. The SWD approach sounds interesting. I guess that the master could
program the slave via SWD. Do you know if the source code of the PICO as
SWD debugger is available?
…On Sat, Apr 22, 2023 at 6:14 AM Richard Hulme ***@***.***> wrote:
On a fresh unit, the flashloader (plus application) is programmed either
via USB or via the debug interface (SWD).
Theoretically the master could also be connected to each of the slaves'
SPI flash chips and be able to program them that way but that's not really
feasible with a standard Pico board as the SPI lines to the flash chip are
not brought out to any pins or test pads. The master would also have to be
able to make sure that any given slave was not actually running when
programmed (or you would have two SPI masters trying to control the same
chip).
Even if only the master has a USB connection during normal use, I would be
wary of designing a board that gave me no way at all of physically
connecting to each slave (whether via USB or SWD) as there would be no
(easy) way to recover a board in the event of a software problem.
—
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQVMQJHAXQOPDEDMCHJTMDXCPKUVANCNFSM6AAAAAAXHLRKXI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
So if you're populating the individual chips, you could run SPI tracks between the master RP2040 and each of the slaves' flash chips. You'd need separate CS lines for each slave. As long as the slave RP2040 is not running, you should be OK so you either need to control the power to each slave or hold it in reset during programming (I've never looked into doing this so you'd need to check the datasheet to make sure there are no issues). If you have multiple slaves, you either need to "disable" each slave individually or all of them together. Which you do depends on what your requirements are but individually means you'll again need a separate pin for each slave (you might be able to combine it with the CS line but you'll have to be careful that the "disable" action (whether power or reset) only happens in that scenario and not when the slave itself asserts the CS line in normal use (or when the BOOTSEL button is pressed). How feasible this all is depends on how many free pins you have on the master and how many slaves you need to control. SWD is probably more work on the software side. The source code for PicoProbe is here: https://github.com/raspberrypi/picoprobe The hardware connection via SWD is two lines per slave, which may end up being less than speaking directly to the SPI chips (depending on the number of slaves) but you'll have to make the SWD code be able to switch between different sets of pins (unless you use some external multiplexer). I've never done anything with SWD at a code level (other that just using PicoProbe). My guess is that going the SPI route is probably simpler and more reliable. Personally I would tend not to put this code into the flashloader on the master as it will add a lot of complexity, which turn increases the risk of bugs (which will affect the reliability of updating the master itself). Probably better to have it in the master application (e.g. check at application start if the slaves have the right firmware and update them before continuing with the main application). |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I'm attempting to use pico-flash loader to implement if in my project, with 12 picos connected to an I2C bus as slave, and one esp32 as master. I manage to have a very simple dynamic I2C address allocation thanks to a "signal-in" "signal-out" ring (initiated and ended by the ESP), and I2C broadcast messages to ask slaves to "take" an address. Only the one that has the "signal-in high" take the address, respond to the master query, and raise its signal-out pin to high for the next pico and so on. |
Beta Was this translation helpful? Give feedback.
-
|
I've only used the SWD port very occasionally so I don't remember all of the details, but there's information in chapter 5.3 "Loading a Program" in the "Getting started with Raspberry Pi Pico" document (see https://www.raspberrypi.com/documentation/microcontrollers/raspberry-pi-pico.html#raspberry-pi-pico). Since I assume the 'program' command only erases the area of memory referred to in the .elf file, I assume you should be able to run the command twice (once for each .elf file). |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your hints, I will give it a try to check if I can solder the picos before any "usb magic step", and also if I can manage to rescue any pico one soldered on my - very busy - PCB without any space for USB, as for some other projects. |
Beta Was this translation helpful? Give feedback.
-
|
So, just to share: flashing is fine through openocd command. No "offset" is needed to import the .elf files, just run the pico to flash "pico-flash loader.elf" then with your application.elf (built with your script). I was afraid of having to manage specific option with memory offsets, but the offset look to be already present in the .elf file (magic for me, due to your work with the ld files) and after flashing both, the application starts without any issue. Several flash of the application is then working correctly, as my I2C code for flashing is not yet fully functional. Thanks so much for your work, it solved one tricky point in my project. |
Beta Was this translation helpful? Give feedback.
-
|
OK. Glad you got openocd working. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, for reference (and if someone else read this thread for a similar usage). Seems that I was wrong / or I did a wrong test when flashing my picos, that was not showing that the 2 sequencial writes were functionning correctly. I finaly added a custom script to perform the binary contatenation (with 0xff padding to respect the 4096 boundary), and upload it with the command : |
Beta Was this translation helpful? Give feedback.
-
How the flashloader is programed in flash in the first place? Is USB port still required?
I am designing a board with a few slave PICO's that are connected to a master PICO (e.g. via SPI) and only the master PICO has USB connector. Can the master program virgin slaves with the bootloader firmware?
Beta Was this translation helpful? Give feedback.
All reactions