View previous topic :: View next topic |
Author |
Message |
Paulvk
Joined: 28 Jul 2006 Posts: 1257 Location: SYDNEY
|
Posted: Sat Jun 01, 2013 3:10 am Post subject: |
|
|
My thoughts were the boot loader checks for the version and the running program updates the ok flag you will need a watch dog to get it to run if it locks up but when the boot loader runs again (as Adrian says first) it checks the version sees no ok then loads the previous version if it sees the ok it just runs the program in flash.
Regards Paul |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Sat Jun 01, 2013 12:32 pm Post subject: |
|
|
what i did for a project with m2560 that did not use all the space(uses only halve the space) : i add the binary file to image file at a higher location.
at the push of a button the user can then copy the code back from the loaded backup.
but i made a remark for myself : it is better to use an external eeprom and store the received file to that location. you could also store multiple versions.
and when the checksum matches, the data is programmed from the eeprom. bottom line is that you only start theactual programming, once you have a known good image. and that during this programming, the process is not interrupted.
as was remarked before : you should always run the bootloader first thing. i have it checked a flag in eeprom at a shared location. so i can determine if an update is needed, or in process. _________________ Mark |
|
Back to top |
|
|
nicofer
Joined: 01 May 2013 Posts: 90 Location: GRJ
|
Posted: Wed Jun 12, 2013 9:45 pm Post subject: |
|
|
Hi
Have not tested any code but just want to confirm thet it will also work in CAN128 cpu ?
Next cool plan will be to get the cpu to link via GPRS and receive a new ver of code - save it to the sd card.
Do a few checks to make sure new file is spotless.
And start the re-flash program .
Cheers |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Wed Jun 12, 2013 11:08 pm Post subject: |
|
|
sure, why not? it will work with any chip. _________________ Mark |
|
Back to top |
|
|
mmarlette
Joined: 30 Nov 2007 Posts: 311 Location: Delano, MN
|
Posted: Wed Jul 03, 2013 6:22 pm Post subject: |
|
|
I have purchased the AVR-DOS Professional license and I have written a custom AVR-DOS .lib/lbx to contain only READ functions. This was critical to me as I wanted to modify this bootloader and add several features. It just wouldn't fit. Never worked in libraries before but I got the hang of it and in a day had the new .lib/lbx created and working.
Currently the serial comm debugging has been added with more enhanced output, CRC16 computed on target FLASH.bin(encryption supported) along with the CRC16 value being stored in EE so that it can be compared to the file contents at next boot to determine if reprogramming is necessary, since file renaming requires a library that would write to the device.
This is all working and fits in the target ATxmega128a1 on the Atmel Xplained board. Last check I had 726 bytes left, since I was 740 bytes over when I started, just adding in the serial debugger, it has been a great project over the past several days.
Now several of the calls had to be modified since if a sector has changed, etc....This won't happen in the boot sequence cause we are reading only, so they were removed, code modified so that it would execute properly.
I also added some more serial debugging commands that display for fuse and lockbit settings.
In doing so I have come across this anomaly and I have been unable to determine how this is being done.
The code:
Code: |
Function Read_Fuses(byval Fuse_address As Byte)as Byte
Nvm_addr0 = Fuse_address ' load Addressbyte 0
Nvm_addr1 = 0 ' load Addressbyte 1
Nvm_addr2 = 0 ' load Addressbyte 2
Nvm_cmd = &H07 ' Read fuse byte at index ADDR0 into DATA0
Cpu_ccp = &HD8 ' 0xD8 IOREG Protected IO register (this disables interrupts for 4 cycles)
Nvm_ctrla.0 = 1 ' Non-Volatile Memory Command Execute
Bitwait Nvm_status.7 , Reset ' wait till bit is 0
Read_fuses = Nvm_data0
Nvm_cmd = 0
End Function
'===============================================================================
Sub Write_LockBits(lockbyte As Byte)
Nvm_data0 = Lockbyte
Nvm_data1 = 0
Nvm_data2 = 0
Nvm_cmd = &H08 ' Load the NVM CMD register with the Write Lock Bit command
Cpu_ccp = &HD8 ' 0xD8 IOREG Protected IO register (this disables interrupts for 4 cycles)
Nvm_ctrla.0 = 1 ' Non-Volatile Memory Command Execute
Bitwait Nvm_status.7 , Reset ' wait till bit is 0
Nvm_cmd = 0
#if debugflag
print #DebugChannel , "LW=$" ; Hex(Nvm_lockbits)
#endif
End Sub
'===============================================================================
Function Read_LockBits()as Byte
Read_LockBits = Nvm_lockbits
#if debugflag
print #DebugChannel , "LR=$" ; Hex(Nvm_lockbits)
#endif
End Function
'===============================================================================
|
The question:
The Read_Fuses and Write_LockBits routines make sense per the datasheet, pg 363 of the xmega A manual.
The anomaly I am seeing is that when I am setting up to program the part, the lockbits are read, they are $14(lockdown) so I want to open up the lockbits to allow the flashing. So I Write_LockBits to $ff(all unlocked). This works...
From the code above the Write_Lockbits DOES change the lockbit to allow FLASHing of a new program to occur. What happens is that the debug output from the print statement reflects the state of the lockbits prior to the write. At the point of the debug print, I know the lockbits are in fact changed and are $ff. AVRISP mkII verified or if you don't set to $ff, the bootloader will continue to try and reprogram the part at next reset or powerup.
So the strange part to me....is that in the table on pg 363, there is no READ_LOCK_BITS command. So how is NVM_lockbits being updated?
I thought maybe you have to read the fuses again but there is no address for the lock bits? Or have I missed them...that datasheet is huge.......
What am I missing??
Going back to the datasheet......
TIA,
Mark |
|
Back to top |
|
|
mmarlette
Joined: 30 Nov 2007 Posts: 311 Location: Delano, MN
|
Posted: Wed Jul 03, 2013 7:55 pm Post subject: |
|
|
Always better to answer your own questions....
Talking it through, etc....
Page 28 of the manual.....Ahhh it is a register and the register needs to be read......
I will make the minor adjustment.
Regards,
Mark |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Wed Jul 03, 2013 8:38 pm Post subject: |
|
|
good to hear it worked out. _________________ Mark |
|
Back to top |
|
|
mmarlette
Joined: 30 Nov 2007 Posts: 311 Location: Delano, MN
|
Posted: Wed Jul 03, 2013 10:17 pm Post subject: |
|
|
Mark,
Problem #1
Sounded simple enough but it is not working correctly in the Write_LockBits.
The Nvm_lockbits is still the previous value BEFORE the write occurs even when the register is reread before the print is performed.
I know it is changing, not sure what is going on. I corrected the debug output by displaying the lockbyte that is passed to the routine.
As this works, it is an open loop operation. Rereading the register and verifying that the actual register changed is proper, closed loop approach.
Any ideas?
Problem #2:
In the code there is reference to a conditional test using the IF statement as follows. Note function in IF statement.
Code: |
if Read_LockBits() <> LockOPEN Then ' Read lockbits open?
Write_lockbits LockOPEN ' No device locked, open up now
end If
|
The Read_LockBits function is the same as listed above. Normally in the past functions had to be done like this, as I recall......
Code: |
btemp1 = Read_LockBits() ' Read LockBits
if btemp1 <> LockOPEN Then ' LockBits open?
Write_lockbits LockOPEN ' No device locked, open up now
end If
|
The first case will ALWAYS call the Write_Lockbits routine even when the two tests are equal, in this case both are equal to $ff and it will still write. The second case will evaluate properly and branch accordingly.
The other case I ran across this similar anomaly was in this: Note EE dim'd var in IF statment
Code: |
if intCRC <> EE_intCRC16 then ' does computed CRC = value of the last programmed CRC in EE?
GoSub FlashBin ' Size OK, go FLASH part
endif
|
To properly evaluate had to do this, like I recall from older versions of the compiler: Note both SRAM vars had to read EE-SRAM to get it to work properly.
Code: |
intTemp = EE_intCRC16 ' retrieve last programmed CRC value from EE
if intCRC <> intTemp then ' does computed CRC = value of the last programmed CRC in EE?
GoSub FlashBin ' go FLASH part
endif
|
First case will call FlashBin even when the two test conditions are identical.
The second case properly tests and branches accordingly.
In either case there is no error from the compiler.
What is the proper method...I know... the one that works..... But what was happening is that the part was being FLASH every time on reset or power up, which is not good....Only analyzing the debug output and validating the code, raised this issue.
Please advise.
Once these issues are resolved and the .lbx is approved for distribution.... I will upload the complete package to this thread.
Attached is the current screen shot of the debug output. First sequence is insertion of SD after the bootloader was programmed. The second sequence is the autoloader's self induced reset after programming....hopefully you can see that the P did not take place and that the CRC from the file(CF) and of the CRC of the last program sequence in EE(CE) are the same. Thus no programming occurred.
This output has the lockbyte being displayed rather than the actual Read_LockBits.......
I see an extra LW in the second sequence that should be occurring....Will go fix that... LR=Lockbits READ, LW=Lockbits WRITE
Regards,
Mark |
|
Back to top |
|
|
mmarlette
Joined: 30 Nov 2007 Posts: 311 Location: Delano, MN
|
Posted: Thu Jul 04, 2013 5:32 pm Post subject: |
|
|
Ok, Mark has authorized the distribution of the .lbx.
Here is the package, Visual Basic 6sp6 CRC16 app included.
The output screen changed at v2.2 from the above post. Improved output.
The debug code output is as follows and is contained in XmegaBootloader.bas module.
'==============================================================================
' Output of bootloader on RS232
' Vx.xx .. Version of Xmega Bootlaoder
' + ...... Pin Check PASSED
' * ...... Pin Check FAILED
' Fx=$ ... Fuse Byte x, displayed in hex
' LR=$ ... Lockbits READ, displayed in hex
' LW=$ ... Lockbits WRITE, displayed in hex
' B ...... Boot loader started
' C ...... Check Card
' D ...... Init DOS File System
' N ...... No boot file found
' I ...... DOS-Error during file-opening
' S ...... Size-Error of Flash-File
' CF=$ ... Computed CRC16 of target FLASH file, displayed in hex
' CE=$ ... CRC16 of last FLASH/programming sequence, displayed in hex
' P ...... Program Flash
' E ...... Encrypted File Mode
' M ...... Start of Main program
' Err=$ .. Error occured, displayed in hex
'==============================================================================
uggh, looks better in the source with fixed width font format.....
The screen shot shows two boot cycles. The first, programming occurs due to the mismatch of the CRCs. The second, is invoked by pressing reset and watching the boot cycle. Since the CRCs match, no programming occurs.
At this version release, v2.20, there is 694 bytes left over in the bootloader section.
This was tested on the Xplained Xmega128a1 board. The library should work on the ATmega platform, I have a test case just haven't tried it. The XmegaBootloader.bas program would have to turn off encryption as at this point I haven't added an encryption / decryption method....not that hard to add that in.
Remember....This version of the .lbx will not allow ANY writes to occur to the SD. Any effort to add functions to do this will result in errors from the compiler. In effort to try in resolve will result in the code over running the 8K bootloader area.
Enjoy,
Mark |
|
Back to top |
|
|
toto
|
Posted: Thu Jul 25, 2013 11:15 am Post subject: |
|
|
Hello
I use this great bootloader to update firmware trough the SD card during the development time. This works great on Atmega2560, but only with
SD <= 2GB
This card's are dificult to get know and i try to use a 4GB sd card with no sucess. I have try anything, nothing helps. Compile it with
version 2.0.7.2 and 2.0.7.6 but the same result.
Have anyone sucess with this problem? If yes, is possible to help me with sample code or show me the right way?
Thanks in advance
Best regards
toto |
|
Back to top |
|
|
Paulvk
Joined: 28 Jul 2006 Posts: 1257 Location: SYDNEY
|
Posted: Thu Jul 25, 2013 12:49 pm Post subject: |
|
|
Hello toto
In the past when PCs could not read hard drives beyond a certain size they were tricked by creating a partition on the drive only as large as they could read using partitioning software maybe this may work here too you can try the Linux Partition Magic software. I have a similar problem yet to explore with some sewing machines which can only read 128 megabyte compact flash cards, not in production for many years!
Regards Paul |
|
Back to top |
|
|
mmarlette
Joined: 30 Nov 2007 Posts: 311 Location: Delano, MN
|
Posted: Thu Jul 25, 2013 1:44 pm Post subject: |
|
|
@toto- Are you referring to the XmegaBootloader_v2_20.zip above or the other ones in this thread?
When I was researching this topic I found that some of the other solutions used older versions of the AVR-DOS library.
So it is quite possible that the AVR-DOS library at that time didn't support SDHC. SD and SDHC are different in the way you talk to them at initialization.
Now if it is a problem with my .lib above, which was created with the current version of AVR-DOS. Then that is a problem.
As the title of the .zip indicates it is for a Xmega, the AVR-DOS.lbx ****should**** work on the ATmega platform. I have not tested it on that platform due to my target was the Xmega and always short on time....
Some conditionals needs to change, turn off the encryption for one as the ATmega doesn't have AES/DES built in.
Please advise which software is not working.
Thanks,
Mark |
|
Back to top |
|
|
toto
|
Posted: Thu Jul 25, 2013 5:07 pm Post subject: |
|
|
Hello mmarlette,
No, it isn't your Xmegabootloader. I mean the Bootloader from Josef, date 2009.
Like i said, i use it to make firmware updates, but only with SD cards <= 2GB
Xmega i not use yet. My next project is for Xmega128A1. Perhaps i can use your
boootloader to update the firmware trough the 4GB SD card.
Can you modify your xmega bootloader for Atmega2560? I can than test it.
I have not enough knowledge to change you code
Thanks in advance
toto |
|
Back to top |
|
|
mmarlette
Joined: 30 Nov 2007 Posts: 311 Location: Delano, MN
|
Posted: Thu Jul 25, 2013 7:16 pm Post subject: |
|
|
toto wrote: | Hello mmarlette,
No, it isn't your Xmegabootloader. I mean the Bootloader from Josef, date 2009.
Like i said, i use it to make firmware updates, but only with SD cards <= 2GB
|
Whew... I would have to look at the revisions...but safe to say, since it doesn't work, that 2009 .lbx doesn't support SDHC.
With that said, the AVR-DOS_Bootloader.LBX should work in your boot loader. Make the changes to the AVR-DOS config files to use the AVR-DOS_Bootloader.LBX instead of the older AVR-DOS.lbx library. ****IF*** your bootloader DOES NOT try to perform any WRITE functions to the SD, it should work after it is compiled. Any references that try to write will produces errors when compiled. For instance, some bootloaders will try to RENAME the file after it has updated, this is a WRITE function. This bootloader will calculate the CRC and save to EE, so the next boot cycle, the values are compared(READ) only and if different, then will read the master.bin file and FLASH/update.
As it might seem impossible. This AVR-DOS_Bootloader.LBX was my first attempt as BASCOM libraries. Pretty simple, did the whole bootloader and custom .lbx is a few days. Most of the time was spent getting the correct calls into the new .lib to make the .lbx. I had to modify a few calls as they wanted write. For instance, if CLOSE is called and the data was modified, it will perform a WRITE. Since I knew we were reading, this would NEVER happen in the bootloader and modified the assembly language library to not reference the write routine and branch properly on this condition, etc.
toto wrote: |
Xmega i not use yet. My next project is for Xmega128A1. Perhaps i can use your
boootloader to update the firmware trough the 4GB SD card.
Can you modify your xmega bootloader for Atmega2560? I can than test it.
I have not enough knowledge to change you code
Thanks in advance
toto |
Sure I could but I don't currently have the time to do it gratis. Way behind on my products that I am bringing to market.
Any case, enjoy. This was a great learning experience for me and reinforces what a GREAT tool BASCOM has become. All of my questions were answered by the information in these forums. Just have to dig and think.
Regards,
Mark |
|
Back to top |
|
|
Matrixx
Joined: 30 Nov 2005 Posts: 158
|
Posted: Fri Feb 27, 2015 5:59 am Post subject: |
|
|
Hello,
I have used the bootloader with the Atmega2560 for some time.
Has someone tried to use with Atmega1281...?
I will use with Atmega1281 but not sure if it needs to change something.
The version I use is from earlier posts, I see it exist for Xmega too. Thanks all that made it possible, I still say is one of the best things to update the miscro from the SD. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You cannot download files in this forum
|
|