Bootloader on FiPy
-
Is there any way on interacting with second-stage bootloader of FiPy. I would like to add some extra code before the standard flow. Starting a project from visual studio code does not give any access to bootloader stages.
-
@jcaron Are there any list of compatible jtag that can be used with FiPy. I am trying to connect with IAR J-Link jtag but I am not able to find the Xtensa® dual–core 32–bit LX6 microprocessor.
-
@Kostas-Nomikos By the time you can use MicroPython functions a lot more than just the bootloader has run. But I personally have no idea, I'll let you go through the source code to look for yourself. Note that some parts of the ESP-IDF are not open source so there may be things happening that are not visible in the source. You'll probably have to disassemble a few things if you want to know the full story. And a JTAG debugger would probably be extremely helpful given what you are trying to do.
-
@jcaron Does the bootloader initialize the hole SRAM? I mean when I use the uctypes.bytes_at(0x3f9510a0, 32) command I get a standard pattern of bytes. Is there any other part of SRAM which is not being affected by the bootloader?
-
@Kostas-Nomikos You'd have to check the bootloader code for that, but I would be surprised if the bootloader used all RAM.
-
@jcaron said in Bootloader on FiPy:
esptool
The goal is to read the internal SRAM before being written by the bootloader. I am trying to use the internal flash in order to create an SRAM PUF(physical unclonable function). I need to extract SRAM random values on the device power-on. Is there any part of RAM not being affected by the bootloader?
-
@Kostas-Nomikos The bootloader is very low level, it's clearly outside of PyMakr. You'll probably need to switch to JTAG debugging if you do anything in there. I believe you can flash the bootloader with the standard esptool, but if you flash the FiPy with a buggy bootloader and you don't have JTAG you'll just brick the device.
It's probably a much better idea to make the changes to the firmware rather than the bootloader: if your firmware crashes, the bootloader will still be there to re-flash a new version. Also there I believe there is very limited space in the bootloader. JTAG would probably help in this case as well, but you can probably live without depending on what changes you want to perform.
If you told us exactly what it is you want to change you may give you better options.
-
Hi @jcaron. Thanks for the quick response. I would like to make one more question. Is there any way of debugging the bootloader in the device? After making the changes in the bootloader how do I load it in the standard PyMakr flow on an existing project? Furthermore, is there any example of modifying the firmware image.
-
@Kostas-Nomikos Depends on what you mean by "interacting".
You can customise the bootloader at will: https://github.com/pycom/pycom-micropython-sigfox/tree/Dev/esp32/bootloader
You will need to then build and flash that. Also note that in some cases changing some values in the bootloader may have consequences elsewhere (partition table and associated parameters of flashing software).
Of course it requires coding in C (or assembler).
Instead of changing the bootloader, you could also modify the firmware image itself. The practical implications are similar, but it's a lot less risky. If you crash the bootloader you may be in quite a bit of trouble.