View previous topic :: View next topic |
Author |
Message |
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Thu Aug 21, 2014 9:19 pm Post subject: i2c bootloader |
|
|
Hi,
I'm currently working on a large Project (3 AVR's communicating per i2c). I have the Basic code working, including uploading Firmware to the main CPU per Radio (atmega1284/zigbee) but I'd also want to update the slave CPU's (atmega88).
My plan is to include the slave Firmware in the master Firmware as a "binary blob" and update the slaves per i2c. Something like check Firmware Version on slave with the blob Version, if it's different upload new Firmware per i2c.
My question is does anyone have i2c slave bootloader code they can send me? I already have the i2c slave lib, I just Need the bootloader code.
Regards
Ian Dobson
(BASCOM-AVR version : 2.0.7.7 ) _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
Tubeampman
Joined: 27 Feb 2006 Posts: 100 Location: Bodo
|
Posted: Thu Aug 21, 2014 9:55 pm Post subject: |
|
|
Hi
Thats a good question, am working on a Electronic car throttleactuator and i use 2 cpu`s that Control each other.
So i was also wondering if someone has done what you describe.
That way i only need to send one file to update the soft.
Øyvind |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Fri Aug 22, 2014 10:45 am Post subject: |
|
|
Hi,
I already have a working bootloader for i2c. It dodn't take Long to take the Standard bascom code and replace the UART code with i2c code.
The only Problem I'm having at the Moment is with jumping into/outof the bootload/main app. The AVR seems to Crash sometimes, mainly going from the main app to the bootloader, I have a Feeling it's something to do with Interrupts and the Interrupt Redirect Register but my brain is too burned to understand it on a friday afternoon.
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Fri Aug 22, 2014 11:15 am Post subject: |
|
|
Hi,
Switch my brain on and solved the Problem. To jump from the main app to the bootloader I just use the watchdog timer.
The code still isn't that nice but it works, I'll tidy it up sometime
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Fri Aug 22, 2014 11:46 am Post subject: |
|
|
yes the usage of a WD timer is best to create a reset. It will put registers in their default state too.
GOTO will also work but you need to disable interrupts before you use GOTO. _________________ Mark |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Fri Aug 22, 2014 6:17 pm Post subject: |
|
|
Hi,
The biggest Problem I am having is with the $bootvector/Config Intvectorselection = Boot/Normal.
In my main app I had
Code: |
Disable interrupts
Config Intvectorselection = Normal
goto _reset
|
That worked sometimes, other times the bootloader didn't initalise the i2c Pins correctly causing the main CPU to hang.
Using
Code: |
disable Interrupts
config watchdog=128
enable watchdog
do:loop
|
works, even though it feels a bit like a hack.
Once I get the checksum/error handling working I'll see if I can release the code.
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
Tubeampman
Joined: 27 Feb 2006 Posts: 100 Location: Bodo
|
Posted: Fri Aug 22, 2014 11:27 pm Post subject: |
|
|
Hi
that would be very much appreciated
Thanx
Øyvind |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Sat Aug 23, 2014 7:55 am Post subject: |
|
|
Hi,
Although I'm writing this in my free time I'll be using it in a product for my Company, so I imagine I can't release all the code. But I should be able to release the Basic routines.
To use the i2c bootloader you need the i2c slave lib, and a CPU that supports the $BOOTVECTOR compiler directive (interrupt vector table). The code is about 1Kb is size.
In my tests it takes about 3 seconds to upload/flash 1Kb of code with debugging enabled at 100Khz i2c speed, with debugging disabled it's about 0.7Kb/sec.
Tubeampman if you let me know your email address, I'll send you a copy of the code.
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
Tubeampman
Joined: 27 Feb 2006 Posts: 100 Location: Bodo
|
Posted: Sat Aug 23, 2014 12:46 pm Post subject: |
|
|
Hi
my email is fixmann@online.no
thanx for helping me
By the way here is a early Version og the throttle https://www.youtube.com/watch?v=jseSuFb9ibQ
After some work it runs real smooth now, a friend of me is writing a nice gui for settiup the throttle (response curve, PID setting and so on)
I will implement failsafe and limp home mode, cruisecontroll, TPS output for ECU, IDLE input from ECU, brakepedal input +++
Here it would be Nice to use a I2C bootloader since i use 2 cpus that contolls each other (Dont want to make a replica of the Toyota killings).
Øyvind |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Mon Aug 25, 2014 5:52 pm Post subject: |
|
|
Hi Mark,
I'm currently having a few really strange problems:
When I reload the bootloader through ISP, the first time I load the main firmware per I2C everything works. If I then jump back into the bootloader (i2c command from the Main CPU to the Slave) I can update the firmware but the jump to the main app fails at random points in the main app (Always after enabling interrupts).
In the main app I use the watchdog reset to jump to the bootloader. The bootloader jumps to _reset if bootloader shouldn't run, and q watchdog reset to exit the bootloader after updating the main app.
Code: |
Program flow
Main app
set Intvectorselection = Normal
Enable interrupts
if Firmware Update command sent
Set EEPROM flag
watchdog enabled
Reset ---> Bootloader
If EEPROM flag not set, Intvectorselection = Normal then goto _reset
set Intvectorselection =boot
Enable interrupts
Upload new firmware
Firmware uploaded OK, clear EEPROM flag
watchdog enabled
Reset ----> Reset into bootloader
|
The problem seems to be that the when I re-enable interrupts in the main app the CPU sometimes crashes after a random period of time. These crashes don't happen if I load the main app per ISP. It's as if the ISV flag isn't being set correctly.
Note the Intvectorselection is always set correctly before casing a watchdog reset or goto _reset.
The code is running on a atmega88@8MHz internal clock, i2c clock 100KHz, Bootloader 1024 words, Reset vector Boot. The bootloader uses i2c slave address 200 and the main app uses address 90 or 92 depending on configuration. Only 1 slave is active at the moment.
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Mon Aug 25, 2014 10:27 pm Post subject: |
|
|
in the bootloader, turn global interrupts off first thing.
or turn them off before you activate the WD to call the boot loader. _________________ Mark |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Sun Aug 31, 2014 3:34 pm Post subject: |
|
|
Hi,
OK, finally got the code working 100%. I'll comment the code/tidy it up sometime next week and then post it here. The most important thing is to use the watchdog to reset the CPU as often as possible (Upload finished, set EEPROM flag, watchdog reset, flag seen hump to main app).
Performance is quite good, uploading 3.5K takes about 4 seconds with a 64byte page size. Error handling is limited, but in my tests (Uploading various versions of the Slave application 500 times) I've not had a transfer error.
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
Deanus
Joined: 26 May 2006 Posts: 188 Location: Adelaide
|
Posted: Sun Aug 31, 2014 9:22 pm Post subject: |
|
|
Well done Ian and to those that assisted, it's always interesting to watch the developments
of projects and then finally have a good outcome, and a useful bit of code as well.
Regards
Dean |
|
Back to top |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
Posted: Mon Sep 01, 2014 4:43 pm Post subject: |
|
|
Hi Deanus,
The i2c bootloader was only a small piece of a much larger project (20 i2c sensors, zigbee radio comms, Battery driven by Li-ion SMbus batteries). The whole thing should "just work", driven by a simple windows application.
The i2c bootloader will allow me to update the code on the main CPU (over zigbee), when there is a newer version of the slave firmware (embedded in the main CPU firmware) the slave is automagically updated. All with a few simple clicks/selecting the firmware file to load.
Regards
Ian Dobson _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
Deanus
Joined: 26 May 2006 Posts: 188 Location: Adelaide
|
Posted: Mon Sep 01, 2014 9:21 pm Post subject: |
|
|
Hi Ian,
The good thing about a project like yours, is that all those attachments & code are working in the end product.
When you go and design your next new product, it's always in the back of your mind that I have all these
things like boot loaders, sensors, radio etc hardware & software already working and fully tested code,
makes the next job much easier & quicker.
Again well done!
Regards
Deanus |
|
Back to top |
|
|
|