Intel hex record type 03 in bootloader

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

I am making a bootloader for ATMEGA32, while testing my bootloader i found that my bootloader hex file consist of record type 03 in it.

firstly i am not getting that what is recoed type 03? why it is used?

Secondly, I am assuming that due to this record type, my bootloader is not working. So is it necessary to include that record type data?

what happens if we don't use that data in it?

 

:0400000300003800C1

 

Thanks

 

 

This topic has a solution.
Last Edited: Fri. Oct 28, 2016 - 11:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You generally only need to worry about these on "large" AVRs. They are the way to break beyond 64K. If you had a line of data to program to 0x2FC80 say then the addressing in the hex would gave 0xF8C0 but the 0x0002 part would be set previously using an 03 record.

 

On your 32K micro this is not applicable - though the tools may insert a 03 record to say "offset from 0x0000" that can be ignored.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry just realised I am talking about 04 records ,not 03. The 03 record is a "start running at this address" record. For AVR it has no meaning. Where the AVR starts running is fixed, either 0x0000 or the BOOTRST/BOOTSZ location.

 

As such you can DEFINITELY ignore any 03 records you may come across.

 

PS forgot to say that putting Intel Hex decode into a bootloader is a very bad idea. The only piece of software in the AVR that must be 100% bug free on day one is the bootloader (anything else can be replaced by it). So adding the complexity of Intel Hex to it makes it very prone to bugs. Why not do Hex to Bin conversion on the PC then just have a protocol where you send start address, length and the then N bytes of contiguous data?

Last Edited: Fri. Oct 28, 2016 - 10:03 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks @clawson

for solving the confusion. i am using a software to convert the intel hex to address and n byte format which will be sent to the AVR.

As i have tested, it is properly working on ATMEGA8 but not on ATMEGA32.

Can tell me any difference in bootloader programming of ATMEGA8 and ATMEGA32. because in data sheet all things are same

other than boot section address?

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

No particular difference. You will generally find that bootloaders and can be recompiled for most of the mega AVRs. Things do get a bit different for Tiny though and are radically different if you move to Xmega.

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

sagar14rocks wrote:

because in data sheet all things are same other than boot section address?

 

In that case are you sure you're using the correct address? Bare in mind the difference between byte address and word address...

 

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

@Howard_Smith I have correctly address the flash page according to the word. As i have already mentioned that this bootloader was successfully implemented on ATMEGA8 device

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

Yes but the boot address for the ATmega32 will be different to the ATmega8 as the bootloader section is at the end of the flash memory. Also the BOOTSZ fuse will make a difference to the boot address too.

 

Edit: You'd already stated that the boot section addresses were different yourself so you obviously already knew that ha! 

Last Edited: Fri. Oct 28, 2016 - 11:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have used 0xCE Low fuse byte and 0x99 as upper fuse byte

and using argument in linker

-Wl,--section-start=.text=0x3800

so that bootloader starts at 0x3800

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

I think you need to tell us more about what "not working" means. What tools do you have to observe operation. In the simplest terms for example, if you put a flash of an LED at the start of the execution of the booloader do you see it when you apply power to the mega32? Better yet, do you have a JTAG ICE? If so can you step through the operation of the mega32 code?

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

The major problem is not because of the code.. but because of the RS485...

when i was using RS232 it was properly sending the bootloader file to the microcontroller..

But when i was using RS485 there was a problem due to tx_enable in it..

we can say that whenever i turn on the tx_enable to make transmit enable... it cannot receive anything

due to mismatch between common signal i.e tx_enable.

i have to use sothing like semaphore or flag to synchronize

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

The way RS4845 usually works is that you use a TXC interrupt. When it signals that the last bit of the last byte has been transmitted out of the UART you then switch the direction of the RS485 so it can receive.

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

Yes, you are right but i don't want to use interrupt in the bootloader.

is there any alternate way without using interrupt to use bootloader on RS485?

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

Poll the TXC flag. Something like:

void tx(char c) {
    UDR = c;
    while (!(FLAG_REG & (1 << TXC)));
    switch_RS485_dir();
}

 

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

What's the issue with using interrupts in the bootloader? I use the USART Receive interrupt in my own bootloader (which is an adaptation of XBoot) without any issues.

However if you really don't want too you could simply pole the transmit complete flag until the last bit of the last byte has been sent (this would've been triggering the TXC interrupt anyway!) and then do your direction switch

Last Edited: Fri. Oct 28, 2016 - 12:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Howard_Smith wrote:
What's the issue with using interrupts in the bootloader?
The bootloader is the only code in the entire AVR that must be 100% bug free on day one (the rest of the code can be replaced/fixed using it). So it needs to be short and simple to ensure that all possible code interactions can be tested. That is fairly easy in synchronous/polling code. As soon as you introduce an interrupt and make it asynchronous the complexity rockets by about X10. There may now be operational scenarios your tests cannot easily cover because you cannot predict when in the operation of other parts the interrupts may occur. It's like you now have two threads of execution with synchronisation issues.

 

Bottom line: keep it simple.

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

clawson wrote:

Howard_Smith wrote:
What's the issue with using interrupts in the bootloader?
The bootloader is the only code in the entire AVR that must be 100% bug free on day one (the rest of the code can be replaced/fixed using it). So it needs to be short and simple to ensure that all possible code interactions can be tested. That is fairly easy in synchronous/polling code. As soon as you introduce an interrupt and make it asynchronous the complexity rockets by about X10. There may now be operational scenarios your tests cannot easily cover because you cannot predict when in the operation of other parts the interrupts may occur. It's like you now have two threads of execution with synchronisation issues.

 

Bottom line: keep it simple.

 

True, I can appreciate that. In my particular case I'm only using the one interrupt and its ISR only has 3 or 4 lines of code in it. I haven't had any problems with it so far but perhaps it's something to look out for and/ or think about...

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

sagar14rocks wrote:
we can say that whenever i turn on the tx_enable to make transmit enable... it cannot receive anything

Well, yeah -- what did you expect?  RS485 is half-duplex.  You must realize that.  How you address the situation (change the protocol; change to RS422; whatever) is up to you.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.