AVR Freaks

No, Optiboot as it stands knows NOTHING about any Bluetooth interface. It just expects to receive and send stk500v1 bootloader protocol commands from a program on the transmitting device. as the connection is expected to be a wired UART link no "set up" (apart from setting baud rates) is required. A Bluetooth link could be quite different - the bootloader may need to star tby sending various configuration commands to the BT module to set up the link before it can then just treat it as if it were a direct wired link as before. So you will need to modify the code to add all that.

Not easily. the fact is that in the case of the wired link and Optiboot being used on an Arduino there is an "additional wire" in the link. When the PC program (avrdude) wants to tell the Arduino+Optiboot to expect software it starts by riggering the extra wire. That wire is in fact the DTr (Data Terminal ready) line of an RS232 interface. The Arudino circuit has that connected to the _RESET pin of the AVR so when that line is triggered the AVR resets and that means it restarts in the bootloader and is immediately ready to hear commands sent over UART to tell it to start the updating process. As Bluetooth is just "fresh air" there can be no concept of an "extra wire". You will probably need to add code to the AVR to let the user initiate some kind of trigger to get the ball rolling.

Silly question but have you already used "simple" bootloaders like Optiboot in an Arduino already. Are you already familiar with the sequence of even such a "simple" link before you go on to try and modify it into being something more complex?

typedef void (* fptr_t)(void);

fptr_t go_to_address;

...

    go_to_address = (fptr_t) 0x1234;
    go_to_address();

modify the 0x1234 for your chosen destination address.

uint8_t eeflag EEMEM;

    eeprom_update_byte(&eeflag, 37);
    go_to_address = (fptr_t) 0x0000;
    go_to_address();

However in this you have no control over what EEPROM location is assigned to "eeflag". You probably want to use a fixed EEPROM location that both the bootloader and the application know that is away from any other potential EEPROM usage. So perhaps use the last byte of EEPROM with something like:

    eeprom_update_byte((uint8_t *)0x3FF, 37);

replacing 0x3FF with whatever the last location in the EEPROM actually is.

The same ISP programmer you use to put bootloaders and other code INTO your AVR chips should be equally able to read the code out of AVRs (to .hex files).

No.

The point with using the "update" rather than the "write" fEEPROM functions is merely about reducing wear on the EEPROM. The "update" version reads the EEPROM and compares it with what is to be written. If there is no difference then the writing will not take place, thus saving an erase-write-cycle. It is erase-write-cycles that wear out the EEPROM, so using the "update" versions is a good habit to have. If you find code that uses the "write" versions it is likely that that code was written before the "update" versions of the EEPROM functions where invented.

You need to get a good book on C++ programming.

The "String" type is something that was added in C++. It takes the original "char data[] = "hello"" (which includes to \x00 at the end) to another level by not only holding the characters but making a number of methods available to operate on those characters:

http://www.cplusplus.com/referen...

So you can do things like the .length() you are using there but you can do things like HexData.insert(4, "hello") and it inserts data into the middle of the string at character position 4 and so on.

Of the many methods available the one you actually want here is called "c_str". That returns the "char data[] = ..." style version of what is in HexData so try:

eeprom_update_block((const void* )HexData.c_str(),(void * )0x01, (size_t)hexsize);

I would highly recommend you use linker assigned addressing in the EEPROM though. If you use your own addresses it becomes your responsibility to ensure you aren't going to get overlaps.

BTW why on earth would you want to write a string of hex data to the EEPROM anyway?

The whole EEPROM thing has been suggested as a "trigger" to say, a the chip starts up, whether or not it should go and try to get new code.

The way a bootloader with a direct UART link usually works is this. At power on the AVR starts running the bootloader first. It enables the UART then starts listening to see if there are some instructions coming in to say "don't continue, in a moment I am going to send you some code for a replacement program". It then starts the bootloading process. If no such instructions are received (or once the program replacement has finished) it then jumps to the application and lets that run. At most subsequent power ons there probably won't be new code available so it will just stop and wait for a while (maybe just a second or two) each time but when it doesn't see a PC trying to get in contact it just goes on and runs the app code.

Now sometimes you want a mechanism where either the app code itself can receive a message while it's running and somehow let the bootloader know that it is required to kick into action. The way you do that is by having the application write a flag byte to EEPROM (say) then even if the device powers off/resets at the next wakeup the bootloader looks at that flag and it is set to say "do your thing".

Someone in this thread or one of the many others you have created has suggested that such an EEPROM flag may help in the case of a Bluetooth link because it's not "instantly on" like a direct wired connection is.

As I've now said several times what I recommend you do is not try to implement this entire thing in one go but start by just making a normal wired UART link between AVR and PC and see how a "simple" bootloader like Optiboot or Fleury actually works. What are the procedures involved. Only when you understand this kind of basic operation inside out will you then be in a position to consider how much more complex things are going to be when you then put a Bluetooth wireless link into the picture.

Exactly how many days/weeks have you been posting questions here about this? In all that time did you not stop for even just 5 minutes to program a bootloader into an AVR and actually see one operate so you have at least a basic idea of how one works?

The basic requirements of a bootloader are that it should be able to receive and reprogram the application flash contents of an AVR. Some offer additional facilities like being able to read back or also being able to update/read the EEPROM too. But the very most basic one just needs to start up the AVR. Look to see if there is new code. If there isn't it just runs what is there already. If there is then it stops and receives the bytes to be programmed and does just that. Anything beyond that are just added features.

PS to give you an idea someone on Freaks once write a "Minimal" bootloader and it fitted into 61 opcodes (I think it was).

What he said. ;-)

Seriously if you don't even recognise what:

  while (!(UART_STATUS_REG & (1 << UART_TRANSMIT_COMPLETE))); // wait until byte sent

is achieving you just aren't in a position to try writing a Bluetooth bootloader. This is the very most basic, fundamental C construct for embedded C programming.

I'd highly recommend that you start reading here:

https://www.avrfreaks.net/forum/t...

That is why it's best to typedef a function pointer type so you can apply it as a typecast to the integer literal. If I wasn't using a tablet I would be able to show an example. May post again later from a PC. 

EDIT: OK like this:

typedef void (*fptr_t)(void);

fptr_t boot_start = (fptr_t)0xF000;

...
  boot_start();

The reason you get the warning otherwise is that 0xF000 is a long int for an AVR. The thing on the left of '=' was a pointer to a function. So you are trying to assign an integer to a pointer. C thinks this is probably a mistake (often it is!) so it warns you. The way you quell that warning is to say "no this 0xF000 number really is a pointer value". The way you do that is with a typecast. Now you could do this with (wait for it):

void (*boot_start)(void) = (void(*)(void))0xF000;

But as you can see in that there is almost exactly the same (quite complex) structure on both side of the equals. So it makes sense to put all that detail into one single typedef and use it in multiple places.

If the function type were more complex this might even be something like:

int (*boot_start)(char, long, int *) = (int (*)(char, long, int *))0xF000;

and this starts to look very silly indeed - not only is it very likely you make a typing error it's just trying to remember the syntax here is a real pain! So you use typedef to define the function interface just once:

typedef int (*myfn_t)(char, long, int *);

myfn_t boot_start  = (myfn_t))0xF000;

and that gets to be easier to type and easier to manage. If you later add a fourth char ** parameter to the function you now do it in just one place - the typedef.

Don't write to me - write to the forum. I'm not the only one here who can answer your questions.

This is a bit like someone who once went on a hill walking holiday in Scotland and this week finds themselves suspended on a climbing rope half way up K2!

The errors here are fundamental to the C programming language which you clearly do not understand yet. You cannot tinker about with bootloader code if you don't even speak the language it is written in!

I'll bet that for:

if ((eeprom_read_byte(uint8_t *0x01)) == '1')

you meant to write:

if ((eeprom_read_byte((uint8_t *)0x01)) == '1')

and if you don't know why I've added () in this and what "(uint8_t *)" is achieving you simply don't know enough C to do this.

I would also question the use of absolute addressing in EEMEM but I have a rather sneaking suspicion you don't actually know what I mean when I say that!

This is the kind of question you should be answering yourself. If it is not obvious the Arduino uses Optiboot and that implements the "stk500" protocol. That is documented here:

http://www.atmel.com/images/doc2...

Oh and here's a coincidence. I just went to look at the Optiboot source code so I googled "Optiboot source code". The top link was not what I was looking for but I think it IS what you are looking for:

https://github.com/NordicSemicon...

So that is a version of Optiboot modified to use a Bluetooth Low Energy module.

I don't suppose the Bluetooth you are trying to use happens to be the "Nordic Semiconductor nRF8001" because if it is that code may be your complete solution. If it isn't then get copies of both the regular Optiboot and this modified one and look at the differences (I use kdiff3 for this myself) and see how they changed it.

Arduino will do that for you! If you add a "-v" to the Arduino command line it tells you a little about what it is doing. Add another "-v" and it tells you a bit more. You can keep adding them up to four of them; by that stage it gets VERY detailed about what is going on and will show you all the bytes it is sending and receiving.

There isn't one. For once work this out for yourself.

I'm not surprised your avatar shows the picture it does!. Just take a moment to drink some tea, relax then have a read through the AVR datasheet.

There are basically 3 fuses involved in using bootloaders in most of the large models of AVR. There is a pair called BOOTSZ0 and BOOTSz1. In combination they select four possible sizes of bootloader. (effectively they are picking where the bootloader starts in flash). Then there is BOOTRST which switches the whole mechanism on/off. When enabled the AVR will fetch the first opcode at power on from the first location of the boot area set by the two other fuses.

To change fuses you use your ISP programmer. To avoid changing anything else it's a good idea to start by reading the current fuse setting. Then you just change BOOTSZ0, BOOTSZ1 and BOOTRST to the combination you want and use your ISP programmer to write that value back. The three fuses are either in the "High" or "Extended" fuse byte usually.