Optiboot 1284p compiled for UART1 instead UART0

Go To Last Post
70 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi ,

 

I have trying to establish a communication between my atmega1284P and bluetooth module HC 05 which could flash hex files into my MCU. I want to flash it via UART1 instead of UART0 as the UART0 is already being used. I tried to start with a custom boot loader, but with my basic knowledge I was not able to write.  Then I found a boot loader called optiboot which had a hex file " Optiboot 1284p compiled for UART1 instead UART0 (experimental)"

 

Has anyone tried to boot load this ? What is the status of this experiment ?. If not how do I change the source code of other optiboot to boot load via UART1.

Please also suggest android app that can be used to flash hex files from mobile to the MCU.

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely it is true of any bootloader (not just Optiboot) that if it has been written for a particular UART in a chip that has more than one UART that you'd just need to change any reference to UDRx or UCSRxA to be UDRy and UCSRyA and so on to switch from one UART to the other? You don't need a boootloader written specifically for one UART as it's surely just the case of changing '1's to '0's or '0's to '1's isn't it? (or '2's or '3's etc)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some of the more recent work in Optiboot has been aimed at making "custom" builds easier.   You should be able to get what you want  without changing any files, just by modifying the make command line:

make BAUD_RATE=9600 UART=1 LED=xx atmega1284

(assuming that you have a relatively reasonable avr-gcc setup installed.)

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which boot loader should I download westfw ? 

 

Can you please share the link of the boot loader ? I found the above stated boot loader in the link " https://code.google.com/archive/... 3rd option". If I am using Windows 10 will the winAVR makefile software would be enough to change these values.  ?

 

And is there any android device which can send hex files to the microcontroller ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use the "download zip" link here: https://github.com/Optiboot/opti...

(there was a recent fuse value fix the 1284, so the "release" is not quite up-to-date. (although that only affects the atmega1284_isp target.))

 

If I am using Windows 10 will the winAVR makefile software would be enough to change these values.  ?

 Hmm.  I'm not sure.  WINAVR should be ok from a compiler point of view, but I haven't tried to use it under W10.

 

And is there any android device which can send hex files to the microcontroller ?

I don't know.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you please write a short tutorial on using this optiboot.zip file to boot load my MCU. The steps to be followed to flash this hex to my microcontroller.

 

Also there are lot of protocols like stk500, stk600, JTAGICE. what are they ?

 

When will be using them ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, I'm not really planning on writing any additional tutorial material in the near future.

Have you read the wiki pages at the github page?  Have you read the assorted Arduino bootloader tutorials?  The Atmel app notes?  Have the read the avrfreaks bootloader tutorial?

Working on a bootloader isn't really all that difficult, but it does require some investment of effort.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi westfw,

 

I understood how dumb my question was when I actually executed it. I am sorry for that. The thing is that, beginner feel difficult to pick up. The idea of customizing boot loader if I knew earlier, I could have saved time.

Anyway, thanks for your help clawson and westfw :) 

It will be helpful for others reading this thread if you can the link of the tutorials whatever you feel would help beginner to get started @westfw

 

 

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

srinivardhan wrote:
It will be helpful for others reading this thread if you can the link of the tutorials

Is your copy of Google not working? When I type "optiboot tutorial" into Google I get:

 

https://forum.arduino.cc/index.p...

 

(look who it is!!). In his post it has:

And the wiki is here: https://github.com/Optiboot/optiboot/wiki

read through every page on that wiki - report back here if anything remains unexplained.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson,

 Thank you for sharing the links, while referring the github wiki pages, It referred that optiboot is compatible to device which has flash size upto 64Kb, but a atmega1284P has a flash size of 128KB.

Will that be a problem ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

srinivardhan wrote:
which has flash size upto 64Kb, but a atmega1284P has a flash size of 128KB.

I read that too. However pay VERY close attention to what it actually says. It says you cannot use a 2560 device because it is too big and the limit is 64KB WORDS - the important word here being "WORDS". 64KB WORDS is 128KB BYTES - so the 1284 should be OK. (in fact we know it is as there are builds of Optiboot for 1284.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson,,

 

OO.. Thank you for pointing out the mistake. I admit. I dint interpret properly. 

 

Now with the boot loader I have compiled for atmega1284P via UART1, will I be able flash hex files through a bluetooth terminal where I can type avrdude commands ?

 

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson and westfw,

 

With optiboot in my atmega1284P, how will it recognize when to reset the MCU to accept new data into flash ? If i am using bluetooth HC-05 to send new hex file to flash ?

 

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

srinivardhan wrote:
will I be able flash hex files through a bluetooth terminal where I can type avrdude commands ?

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.

srinivardhan wrote:
how will it recognize when to reset the MCU to accept new data into flash ?

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh yeah, I was going to mention that there have been assorted problems when people have tried to used optiboot (or other standard bootloaders) over RF links.   One is the lack of auto-reset; you may have to work on timing the use of the reset button (or give up and increase the timeout in the source code.)  Also there is the duplex issues - radios are inherently half-duplex, and most uart bootloader protocols don't include any "line turnaround" logic at all.   You're probably safe with a BT module, since they tend to have a lot of internal smarts and buffering, but more primitive radios might need strategically added delays or something.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
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.

Hi clawson, Thank you for writing that, gives me clear idea.

 

So I need to add the command for communication based on some bluetooth protocol to start communicating with the MCU ?

 

clawson wrote:
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.
 

 

If I can send some command via bluetooth which could wire the RESET pin using the PORTX register and set it high for particular time, will the resetting work ?

And where should I write the bluetooth communication code in the boot loader code ?

 

Say if I do ,

 

<  char j;

if (Serial.available()) // checking for connectivity
  
  { p = Serial.read();   // if true, reading the data into the char "p"
    if (p == "reset")

{

_asm(jmp 0xboot loader section)

} >

 

Is my method right ?

It would be helpful to indicate the modification required to make this possible. 

 

 

westfw wrote:
You're probably safe with a BT module, since they tend to have a lot of internal smarts and buffering,

Hi westfw,

Thank you for writing that. How do I work on timings ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson and westfw,

 

Can I not use a software reset to reset the MCU to accept new data into the MCU ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd probably add the means in the application to accept a command via the bluetooth to store a value into eeprom, then cause a watchdog reset. The bootloader can examine the value in eeprom to see if it has been commanded to run. At that point, the bootloader is in control.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi kartman,

 

Kartman wrote:
I'd probably add the means in the application to accept a command via the bluetooth to store a value into eeprom, then cause a watchdog reset. The bootloader can examine the value in eeprom to see if it has been commanded to run. At that point, the bootloader is in control.

 

As you say, can I burn the normal optiboot boot loader onto my microcontroller, and establish communication with the bluetooth module in the application code and if I send a reset command, it can jump into the boot loader section ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're in control - you can have it play a tune if you like. The only thing special about the bootloader is that it exists in a specific range of addresses so that it is allowed to write to the flash.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do I perform a jump function to jump to a particular address ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many ways - inline assembler, load a function pointer with the address and call the function pointer, do some smart stuff with the linker......
As i suggested earlier you can put a value in a known eeprom location and do a watchdog reset to invoke the bootloader.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do I put a value into a eeprom location before a reset ?

 

Usng eeprom_page_write macro ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

srinivardhan wrote:

How do I perform a jump function to jump to a particular address ?

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.

srinivardhan wrote:
How do I put a value into a eeprom location before a reset ?

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson,

 

If I want to read the memory of the burnt boot loader in atmega2560, what should I do ? How do I read the memory ?

 

 

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

srinivardhan wrote:
If I want to read the memory of the burnt boot loader in atmega2560, what should I do ? How do I read the memory ?

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).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi kartman and clawson,

 

I see writing to eeprom and setting flag to flash seems to be a very good option for my case. I have few doubts over writing to eeprom.

 

1.What are the considerations I need to know before writing to eeprom. 

2. by using "update" instead of "write" in eeprom programming, will it help me if there is an Error in flashing, MCU should able to execute previous version of application code ?

3. How do I use the eeprom registers to read serial value and write to the eeprom.

 

 

While referring the datasheet, I found this section. Can you please explain a little more about it ?

 

 

Attachment(s): 

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

srinivardhan wrote:
2. by using "update" instead of "write" in eeprom programming, will it help me if there is an Error in flashing, MCU should able to execute previous version of application code ?

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Sat. Feb 20, 2016 - 10:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman and clawson,

 

As you suggested I am writing the data in the eeprom using the eeprom_update_block 

Quote:
 int hexsize;
            String HexData;

void loop() {

            HexData = Serial1.readString();

            hexsize = HexData.length();

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

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

}

 

I get this as the error "exit status 1
invalid cast from type 'String' to type 'const void*'"

 

How do I rectify ?

 

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson,

 

I am trying to write the hex data into the EEPROM so that when the control is given to bootloader it can flash the data available in the eeprom.

 

Is it not right ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Far from right. Not even in the same ballpark! You're making a very simple problem into a complex one.

When you have a bootloader - it is the first to execute from reset. The bootloader code has to decide whether it attempts to download new code or runs the existing code. There are a number of ways you can do this.
One method i used was to put a value into one byte of eeprom. You might have something like 0 = run application code, 1= run bootloader download, 2= new code loaded. So for the application to force a download, my application code would write 1 into the eprom then do a watchdog reset. Once reset, the bootloader code sees the 1 value in eeprom so it knows to do a download. Once you've done a successful download, the value 2 is put into the eeprom and the application is run. The application reads the eeprom and if it finds 2, it knows its being run for the first time and might need to initialise some stuff. Once done, it puts 0 into the eeprom.
It's a bit like putting a post-it note on the fridge.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Far from right.
What he said!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Kartman,

 

Oh my god.. I have misunderstood the whole concept wrong. Now I get a little insight about what we were talking. Now then I have to decide the UART I am going to use and how the bootloader should function based on the values in the EEPROM. So merely rewrite my functions of bootloader to check values in eeprom and act accordingly ? 

 

Is this right someway ?

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You're the boss, so think about how you want your magic box to work. Consider what to do if bad application code got loaded? How would you force the bootloader to load new code?
Have you got optiboot working? Start simple then add features.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi kartman,

 

Thank you for pointing it out, can you please say me the basic functionality that a boot loader should must have whatsoever  may be my requirement.

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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).

Last Edited: Mon. Feb 22, 2016 - 12:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson,

 

Thank you for bearing me. I will surely put some work learning the basics and try as you are suggesting. I accept that I am not in a position to understand the workflow so that I could modify the flow.

Thanks for so much care once again clawson and kartman. 

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson and Kartman,

 

I started going about the Peter Fleury bootloader and tried to understand the concepts tried to be established.

In that for data transmission, code given is 

Quote:

static void sendchar(char c)
{
  UART_DATA_REG = c;                    // prepare transmission
  while (!(UART_STATUS_REG & (1 << UART_TRANSMIT_COMPLETE))); // wait until byte sent
  UART_STATUS_REG |= (1 << UART_TRANSMIT_COMPLETE);     // delete TXCflag
}

 

When I read the datasheet in the USART section, it was given the UCSRnA is the status register and it contains the flags like RXCn(8th position), TXCn(7th position), UDREn(6th position) .

In order to set the parameters, like wait until the buffer is empty for transmission, can I not simply write the value of UCSRnA = 0x80 in a "if or while loop" if I want to check for Receive complete flag before transmission instead of the above ?

 

Why is AND operator used between the Status Reg and UART Transmit complete. 

Will be greatly helpful.

Thanks,

Srinivasa Varadhan

Last Edited: Tue. Feb 23, 2016 - 06:26 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'd suggest you start in the tutorials section. A number of us have spent the time to write tutorials so we don't have to keep on explaining the same thing over.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

srinivardhan wrote:
Why is AND operator used between the Status Reg and UART Transmit complete. 

It's not.

 

The AND operator (the bitwise and, to be precise) is applied between the USART status register and a bitmask with a bit set at the UART_TRANSMIT_COMPLETE bit position.

 

The secret on how that bitmask is formed is in the "1<<" stuff.

 

Follow the link 'clawson' gave just above, and read it. Also browse all the follow up posts to the tutorial, since most every question that can be asked has been asked and answered there.

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson , kartman and Johan,

 

This is my serious doubt on the bootloader communication protocols. These are the protocols set by Atmel corporation in order to communicate with Atmel studio or programmers.? If I want to do what kartman suggested, I should write my own communication protocol to communicate via bluetooth ?

 

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This was among the first.

Others followed.

AVR109 https://www.google.com/url?sa=t&...

 

Many bootloaders follow all or a subset of AVR109 and STK500, and are often used with non-Atmel PC side loader apps  of which there are many: BLIPS, avrdude, et al.

 

see "Other Bootloaders" at

see also http://www.nutsvolts.com/magazin...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I want to do what kartman suggested, I should write my own communication protocol to communicate via bluetooth ?

 

No doubt, others have arranged by simple changes to use the Bluetooth serial port extension profile to do bootloading. The Bluetooth link becomes transparent, as is serial over USB, in such a link.

 

Last Edited: Wed. Feb 24, 2016 - 06:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And when I tried to override the default setting of jumping to application section for watchdog time reset to the boot loader section in the Peter bootloader, I am getting this as the error..

Quote:
 invalid conversion from 'long int' to 'void (*)()' [-fpermissive]  

 

I have modified the code like this, 

 

#if defined ( __AVR_ATmega1284P__ )
void (*boot_start)(void) = 0xF000;
#elif defined ( __AVR_ATmega2560__ )
void (*boot_start)(void) = 0x1F000;
#endif

Instead of the code 

void (*app_start)(void) = 0x0000;

 

Thanks,

Srinivasa Varadhan

Last Edited: Wed. Feb 24, 2016 - 08:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Last Edited: Wed. Feb 24, 2016 - 09:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you clawson,

 

As you said it worked. I am working out trial and error method to understand the working of bootloader.

Will write to you on further more doubts.

 

Sincere thanks.

Thanks,

Srinivasa Varadhan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi AVR team,

 

I burned the boot loader with UART pins changed to the UART1, to understand how it works. The problem is the boot loader is set to receive commands so fast and I am unable to send commands that fast. Therefore I want it to wait infinitely if I am going to perform the software update until I complete sending the commands. What part of the Peter Fleury boot loader I should modify. ?

 

I see a initialization that 

#ifdef BLINK_LED_WHILE_WAITING
//  boot_timeout  =  90000;   //* should be about 4 seconds
//  boot_timeout  = 170000;
  boot_timeout  =  20000;   //* should be about 1 second
#else
  boot_timeout  = 3500000; // 7 seconds , approx 2us per step when optimize "s"
#endif
 while (boot_state==0)
  {
    while ((!(Serial_Available())) && (boot_state == 0))    // wait for data
    {
      _delay_ms(0.001);
      boot_timer++;
      if (boot_timer > boot_timeout)

Now say I am connected to Bluetooth in the application code, I send a data "supdate" meaning new software update which would write a data in the EEPROM in the following manner 

if (Serial1.available()) // checking for connectivity

  { p = Serial1.read();   // if true, reading the data into the char "junk"
    if (p == "supdate")   {
        void eeprom_update_byte (uint8_t *0x01 , uint8_t 1234);
    }

 And in the boot loader, if I modify the condition for the timeout in this manner, will my requirement would satisfy ?

 while (boot_state==0)
  {
    while ((!(Serial_Available())) && (boot_state == 0))    // wait for data
    {
      _delay_ms(0.001);
      boot_timer++;
      if(uint8_t eeprom_read_word (const uint8_t *0x01) == 1234)// reading from eeprom
      { boot_timer = 0;
          void eeprom_update_word (uint16_t *0x01 , uint16_t 0000);
      }
      else
      {
       boot_timer++;
       }
      if (boot_timer > boot_timeout)

 

Thanks,

Srinivasa Varadhan

Last Edited: Thu. Feb 25, 2016 - 12:05 PM

Pages