Fitting nRF24L01+ code into a bootloader
A brief follow up to an earlier
post. I previously had a system working whereby I was able to program an Atmega328p chip, using a connected Arduino Nano, but crucially using an nRF24L01+ module rather than a wired UART/PC connection. What I really wanted however was to remove the Arduino Nano, and to program the MCU chip 'directly' by use of a bootloader with nRF24L01+ code to replace with the usual UART functionality. I thought initially that I wouldn't be able to cram the radio module code into a bootloader, but in fact it wasn't too difficult. I used
Optiboot as a starting point and implemented bi-directional radio control within the bootloader. I think it ended up being less than 1024 words (2048 bytes).
I'm not an expert here - but I had to modify the compiler and linker parameters to get things to work:
Compiler flags:
-g -Wall -Os -fno-split-wide-types -mrelax
Linker flags:
-Wl,-section-start=.text=0x7800 -Wl,--section-start=.version=0x7ffe -Wl,--relax -nostartfiles
Note the bootloader has been resized to 1024 words, so the start of the hex file program data is set to 0x7800 (BOOTSZ1 = 0, BOOTSZ0 = 1, hfuse = 0xDA).
I leave this here in case it is ever useful to anyone else. I ran into some really weird bugs which gave me a few headaches, as well as having to return to the radio module datasheet. In the end I suspected some compiler optimisation was causing problems (though removing the compiler flags didn't help), and when I discovered that Bluetooth technology is actually bi-directional radio UART - the very thing I was trying to emulate with the nRF24L01+ modules - I chalked it up as a learning experience and put a pin in it. But hey, I'm learning right! If I were to attempt using a nRF24L01+ code in a bootloader, I would smuggle data back in the returned confirmation packages, rather than switch between the RX and TX radio modes.
Programming with Bluetooth
This is what I would do now! I pinched the picture from
here (circuit untested by me)
Essentially the RESET pin of the chip to be programmed is connected to the 'Connection status' pin of the Bluetooth module in such a way that when the module connects to a Bluetooth programmer, the reset line goes low, the chip is reset, RX/TX data is streamed and the chip is reprogrammed, blissfully unaware that it happening wirelessly, and not over a USB cable. The 'polarity' of the Connection/State pin can be toggled and then wired in directly, or the other polarity could be set and a transitor NOT gate used to invert it. I might try this for myself at some point, but for now, see my
blog post on HC-05 modules. An alternative I have speculated about is whether a chip might be able to reset itself by connecting a pulled-high line to the RESET pin. There are some issues here about timings, and how long a pin needs to be held low for a reset to occur. In some cases, a capacitor has been used to extend and damp the timing of the reset suitably.
Comments
Post a Comment