[SOLVED] BLIPS 4 bootloader via Bluetooth/USART

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

Hi,
I'm trying to set up a bluetooth bootloader for a ATmega168. I use the WT12 transciever on the USART.
I downloaded the bootloader project (bootloader code + windows application) from the project
https://www.avrfreaks.net/index.php?module=Freaks%20Academy&func=viewItem&item_type=project&item_id=625

I edited the asm file with my settings (selected right device/include file, set osc freq and bud rate...), I selected a 512 byte boot size.
I correctly programmed the fuses on the mcu with the isp, and then programmed the bootloader. at this point we've got the bootloader and nothinhg else. when I open the windows application, it reads correcltly the mcu ID, and then erase/program my .hex file into the device. until here everything is working and my program starts: it connects to the pc and sends data as always.
now when i restart the device (turning the power off/on) my program doesn't restart. it seems that the mcu is blocked in the bootloader. from the windows app. at this point I can re-connect to the mcu and obtain the right ID, but it says there are errors if I try to read data from the device and it seems that there are no trace of my program...
any suggetion...?

thx,
bo.

[cliff: moving this to AVR Forum - Academy is for authors of projects to announce/document them - in fact your best bet is probably to PM to 'stevech']

Last Edited: Wed. Mar 4, 2009 - 06:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sorry, I tought this section is also for project releated topics...

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

You say - your program does burn into the flash. And it runs properly. But when you reset the device, your program doesn't restart, it may be "stuck" in the bootloader.

The asm code part of the bootloader has a timer, about 1 second or so (as you choose). When this timer expires, it does a jmp 0. Your code needs to start from there. If you code is in C, the C run time initialization will/should normally go ok then invoke main(). If your code is in asm, check your ORG.

part 2: You say that after you reconnect to the bootloader after reset, it gives the correct chip ID. This means that the boot code is running. But when you read the code, it says there are errors; meaning the hex file contents don't match what's in flash, assuming you have specified the same hex file that was loaded by the boot. Did you run the VERIFY option when you burned? If so, that means the flash was written OK. So this is some sort of confusion, not a bug, I think.

Hope this helps.

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

hi,
today i tryed again, but with no luck...
my project is all written in c, with avrstudio + winavr, so I think there aren't problems.

when I burned the bootloader.hex on the mcu I tryed reading the device from avrstudio with the isp, and I correctly obtained the corresponding hex file. analizing this file it seems all ok, with no code except in the right bootloader area starting from $1F00. at this point I run the BLIPS win.app. and correctly access and program the device: I run the 'Flash erase, write' with the auto verify option selected. it writes the ca.5kb hex file and after everything is completed ok, i send the 'E'xit command to run my program.
At this point my program is running ok. now reading the device with the isp I got a hex file that has the bootloader as before and my program starting at $0000 with the isr vector and so on... this seems so perfect.

but when I restart the device, without sending anythig, it goes back at the previous situation, with only the bootloader code and everythig else empty, as I read in the hex file...

now I really don't know what causes this problem. I haven't changed the bootloader code (except the mcu related defs) and I correctly set the fuses for the 512 byte size and the bootrst. I also tryed protecting the boot section with the lockbits...

any suggestion is welcome...
cheers,
bojan.

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

I finally solved the problem, so i hope this can help others...
at reset, during WT12 initialization, this tranciever sends some data to the mcu, so the bootloader always entered in function, and misinterpreting those data, erased the flash.
now I added a 2-sec timeout at the very begining of the bootloader code, during which I discard all recieved data, and only after that the bootloader waits for a command (erase, program, ecc).
I rised this command timeout to 8 sec, to have time to set up a bluetooth connection between the device and the pc after reset, and then I can send the command from the BLIPS app.
now everything works fine ;)
thanks a lot for the bootloader/app!
cheers,
bojan.