CLawson's SD bootloader implementation on bigger AVR

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

Hello everybody,

I was looking for a SD bootloader and finally I decided to adapt Cliff’s code to my ATmega1284.

I have already searched for any similar post with Cliff’s sd bootloader which implemented to a bigger ATmega, but I didn’t find something.

So, I did some changes and finally I succeeded to compile the bootloader code without errors.

I would like to show you the changes that I have done…

 

*bootloader part*

  • In defined symbols (-D) field
  1. I changed the bootloader start address to BOOT_ADR=0x1E000 (in bytes).
  2. I changed the F_CPU=20000000

 

  • In FLASH segment field
  1. I changed the start bootloader address to .text=0xF000

 

  • In the AVR/GNU Assembler \ General
  1. I changed the assembler flags to –DF_CPU=20000000

 

  • In the asmfunc.S
  1. I replaced all SPMCR registers with SPMCSR
  2. Because I’m using the PA0 as a SD CS pin I wrote these two lines of code in configure.h
#define SD_CS_PORT PORTA
#define SD_CS_DDR  DDRA

and then I did these changes here

#define	DDR_CS	_SFR_IO_ADDR(SD_CS_DDR), CS_PIN   //MMC CS pin (DDR, PORT)
#define	PORT_CS _SFR_IO_ADDR(SD_CS_PORT), CS_PIN
  • In the uart.c

I changed all registers concerning the uart to uart0 since my MC has two uarts.

 

I’m using AS7 and my application code added to the bootloader solution. Like the avrapp in Cliff’s solution.

 

*Now, in the app part.*

In built events tab I wrote the same command with the address correction according to ATmega1284 application size.

 

..\..\srec_cat $(MSBuildProjectDirectory)\$(Configuration)\$(Output File Name).hex -intel -fill 0xFF 0x0000 0xEFFE --l-e-crc16 0xEFFE -o AVRAP001.bin –binary

 

The only changes in this command were the address correction for CRC storage and the .bin file name foo to AVRAP001.

When I tried to build the application project this error pop up.

 

The command "..\..\srec_cat C:\Users\SpaceMan\Desktop\projV3boot\avrapp\Debug\.hex -intel -fill 0xFF 0x0000 0xEFFE --l-e-crc16 0xEFFE -o AVRAP001.bin -binary" exited with code 1.

 I have installed the winAVR and I have a copy of the srec_cat.exe in the path of bootloader project.

 

* This is the build output.*

------ Build started: Project: avrapp, Configuration: Debug AVR ------
Build started.
Project "avrapp.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project "C:\Users\SpaceMan\Desktop\projV3boot\avrapp\avrapp.cproj" (target "Build" depends on it):
	Task "RunCompilerTask"
		Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
		C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe all --jobs 4 --output-sync
		make: Nothing to be done for 'all'.
	Done executing task "RunCompilerTask".
	Task "RunOutputFileVerifyTask"
				Program Memory Usage 	:	50148 bytes   38,3 % Full
				Data Memory Usage 		:	3533 bytes   21,6 % Full
	Done executing task "RunOutputFileVerifyTask".
Done building target "CoreBuild" in project "avrapp.cproj".
Target "PostBuildEvent" in file "C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets" from project "C:\Users\SpaceMan\Desktop\projV3boot\avrapp\avrapp.cproj" (target "Build" depends on it):
	Task "Exec"
		..\..\srec_cat C:\Users\SpaceMan\Desktop\projV3boot\avrapp\Debug\.hex -intel -fill 0xFF 0x0000 0xEFFE --l-e-crc16 0xEFFE -o AVRAP001.bin -binary
		srec_cat: C:\Users\SpaceMan\Desktop\projV3boot\avrapp\Debug\.hex: open: No such
		    file or directory
C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Avr.common.targets(36,5): error: MSB3073: The command "..\..\srec_cat C:\Users\SpaceMan\Desktop\projV3boot\avrapp\Debug\.hex -intel -fill 0xFF 0x0000 0xEFFE --l-e-crc16 0xEFFE -o AVRAP001.bin -binary" exited with code 1.
	Done executing task "Exec" -- FAILED.
Done building target "PostBuildEvent" in project "avrapp.cproj" -- FAILED.
Done building project "avrapp.cproj" -- FAILED.

Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========

 

Can someone help me and explain what does it means the command exited with code 1?

For sure I missed something and especially with the srec_cat procedure.

Thanks in advance.

Last Edited: Tue. Feb 13, 2018 - 09:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kobogia wrote:
Can someone help me and explain what does it means the command exited with code 1?

Well the thing it's complaining about is:

..\..\srec_cat C:\Users\SpaceMan\Desktop\projV3boot\avrapp\Debug\.hex -intel -fill 0xFF 0x0000 0xEFFE --l-e-crc16 0xEFFE -o AVRAP001.bin -binary

Just ".hex" is not a valid filename. Presumably that should really have been something like avrapp.hex ?

 

If you disable the CRC support then you don't need this srec_cat step anyway. Just do an avr-obcopy to convert avrapp.hex to avrapp.bin or even change the original avr-objcopy command so it uses "-O binary" instead of "-O ihex"

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

Thank you Mr. Lawson,

I understood how it works and finally I succeeded to create the *.bin file.

Of course the bootloader doesn't work...! :-)

The “diagnostic” LED is always ON and there is no uart activity.

 

clawson wrote:
If you disable the CRC support then you don't need this srec_cat step anyway.

 

Does it means we use the .hex file instead of *.bin in SD?

 

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

Does it means we use the .hex file instead of *.bin in SD?

No to put an Intel Hex decoder into the bootloader itself would bloat it way beyond my 1..2K design goal. Anyway there are far too many subtleties to iHex (like the lines don't even have to be in address order!) to be able to cope with all that in AVR code. Tools liike avr-objcopy and srec_cat do a far better job of handling iHex than an AVR can. So the file on the card always has to be .bin

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

clawson wrote:
the lines don't even have to be in address order

lots of people fail to realise this and end up in a Big Mess!!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After many attempts I failed to put the boot loader into operation.

I would like to show you which values I have chosen concerning the flash memory addresses and which is the result.

 

First the Flash segment value .text=0x???

(In case of “4096bytes = 2048words” boot size)

According the datasheets of an ATmega1284 the BOOT start address is 0xF800 (in words)

When I build the bootloader with this value the pfboot.hex file starts from F000 and the uart prints always spaces.

 

Now, according to your previous post that I found concerning your bootloader (because of Atmel’s “logic”) I divide the boot start value F800 by 2 and I build the bootloader with this value 0x7C00.

In this case there is correspondence from uart with this message:

B/L start

res=0001

However the pfboot.hex starts from the address F800 which is the correct one according to datasheet.

The strange thing is that it seems to start again from 0x0000 somewhere in the middle of .hex file.

I don’t know if this value is the correct one but behaves better.

 

This is the .hex file : https://1drv.ms/t/s!AjzzbqP8iiOfsBe3MB_6MbGjNaIH

 

Second the BOOT_ADR=0x??? in symbols menu.

According to Cliff’s source code (case ATmega32) the BOOT_ADR value is set to 0x7000 (in bytes) which is the value of datasheet 0x3800 in case of 4K boot size.

In my case if I multiply my boot start address 0xF800 by 2 I have 0x1F000.

Now, In case that the CRC_FLASH is activated and the BOOT_ADR = 0x1F000 I received the message B/L start res=0001 and the LED remains constantly ON.

But if I set the BOOT_ADR = 0xF800 which is the double value of .text=7C00 I’m receiving  this :

B/L start

res=0001

App CRC= 1760

Flash CRC= FFFF

 

And the LED is flashing! It seems to work better because it gives those two information about the CRC.

Of course the SD card was not attached during above attempts.

 

Finally the srec command in the app code.

I have understood that in this command we have to define the last address of the app section minus 2 bytes for CRC’s storage. That means the BOOT start address minus two bytes.

In my case (ATmega1284 - 4K boot size) and according to above settings I have to set this value as follows

0xF800 – 2 = 0xF7FE. This means after build of the code I have a bin file which is only 62K pretty lower than the size that I was expecting 128K – 4K = 124K.

So, I tried to build it with this value 0x1F000 – 2 = 0x1EFFE and I took the ?correct? .bin file 124K.

Of course nothing happened when I inserted the SD card…! sad

 

Can I have your advice please?

Last Edited: Mon. Feb 26, 2018 - 10:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kobogia wrote:
When I build the bootloader with this value the pfboot.hex file starts from F000
Except that before the F000 there is almost certainly an "extended address record" (type 03 is it?) that offsets all subsequent records by 0x10000 so your 0xF000 is really 0x0001F000. It has to be done like this as the address field in Intel Hex is just 16 bits so to address beyond 64K (bytes) there needs to be a way to offset it.

 

Quick Google...

 

https://en.wikipedia.org/wiki/In...

 

OK, I was wrong, extended address is type 0x02 not 0x03. You can see that here:

C:\SysGCC\avr\bin>type avr.c
#include <avr/io.h>

int main(void) {
    while(1) {
    }
}

C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega1284 -Os -Ttext=0x1F000 avr.c -o avr.elf

C:\SysGCC\avr\bin>avr-objcopy -O ihex -j .text avr.elf avr.hex

C:\SysGCC\avr\bin>type avr.hex
:020000021000EC
:10F000000C9446F80C9450F80C9450F80C9450F86A
:10F010000C9450F80C9450F80C9450F80C9450F850
:10F020000C9450F80C9450F80C9450F80C9450F840
:10F030000C9450F80C9450F80C9450F80C9450F830
:10F040000C9450F80C9450F80C9450F80C9450F820
:10F050000C9450F80C9450F80C9450F80C9450F810
:10F060000C9450F80C9450F80C9450F80C9450F800
:10F070000C9450F80C9450F80C9450F80C9450F8F0
:10F080000C9450F80C9450F80C9450F811241FBEB6
:10F09000CFEFD0E4DEBFCDBF0E9452F80C9453F8FE
:0AF0A0000C9400F8FFCFF894FFCFA6
:040000031000F000F9
:00000001FF

That first record breaks down as:

:02 0000 02 1000 EC
  |    |  |    |  |
  |    |  |    |  Checksum
  |    |  |    Offset
  |    |  type 02 = Extended Address
  |    Addr = irrelevant
  Bytes in payload (the 0x1000 value)

So all the 0xF??? addresses after this have 0x10000 added to offset them to 0x1F???

 

I would suggest you cannot develop/debug this without an ICE (I certainly needed it for the "simple" case of sub-64K!) so I'd look at getting an ICE if you don't have one. I think you have about 2 days while the Atmel-ICE is still half-price (using the code). Alternatively, just to get this working switch to a 128K chip that can have one of the old $10 ICEs from ebay attached (so probably a mega128) and get it working there then move that to the 1284.

 

I have boxes and boxes of "free stuff" that Atmel have sent me over the years - I must check to see if there's anything 1284 based in there. If there was I could have a look at this myself.

 

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

This also looks suspicious:

Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').

If you can not make your source code to compile without such errors there will be no hope of flashing it into an AVR and expecting it to do anything usefull.

I don't need an ICE for that.

 

Edit: This seems far to obvious. Am I missing something?

Paul van der Hoeven.
Bunch of old projects with AVR's:
http://www.hoevendesign.com

Last Edited: Tue. Feb 27, 2018 - 07:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I understood how to read a record (text line) in Intel .hex file.
Yes there is this "extended address record" at the beginning of .hex file.
I am using a JTAGICE3. So, I can debug the chip.
I hope you will find an ATmega1284 in your boxes.
Thank you for your detailed answer Clawson.

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

Paulvdh wrote:

This also looks suspicious:

Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').

If you can not make your source code to compile without such errors there will be no hope of flashing it into an AVR and expecting it to do anything usefull.

I don't need an ICE for that.

 

Edit: This seems far to obvious. Am I missing something?

You clearly aren't an AS7 user then? That message is shown by AS7 for ALL builds where there is no prebuild event set. It's basically their obtuse way of saying "no prebuild event set so I'm not doing anything".

kobogia wrote:
I am using a JTAGICE3. So, I can debug the chip.
The issue isn't really about locating the code. It's about how to do SPM to >64K locations. I've never explored that so that's the "new bit" you are going to have to work out using your debugger.

 

EDIT: I just did some googling and looked at the source of some other bootloaders. So it seems the need to expand out the SPM to use RAMPZ as well as just Z only comes at the boundary between 128KB and 256KB of flash. So for a 1284 the existing code *should* be OK.

Last Edited: Wed. Feb 28, 2018 - 02:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Without have any knowledge of assembly I assume that the RAMPZ register is “activated” in Erase and Write page functions here...

#if FLASHEND >= 0x10000
    out	_SFR_IO_ADDR(RAMPZ), r24
#endif

So, as you said the existing code *should* be OK for a 1284.

 

In debugging mode I made two observations,

first I checked from which address the program starts, so I went to the Boot memory section

(2048words size) and the program was started from 1F000 which seems to be the correct one.

second the Program Counter was located in this area 0x00007800...

 

The program seems to be written in correct address but the Program Counter doesn’t read to the correct range.

Can I have your advice please?

 

Attachment(s): 

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

Actually I was wrong. RAMPZ is only needed during SPM for 256K+ devices so 1284 should "just work" as is.
.
BTW what do you mean by "debugging mode"? You mean with an ICE?

Last Edited: Fri. Mar 2, 2018 - 08:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using a JTAGICE3 and is connected to 1284 with JTAG.

I mean during debugging.

Last Edited: Fri. Mar 2, 2018 - 08:22 PM