View previous topic :: View next topic |
Author |
Message |
jwolf
Joined: 18 Jan 2013 Posts: 24
|
Posted: Fri Jul 05, 2013 3:05 pm Post subject: Bootloader suddenly stopped working? |
|
|
I am using a Franzis Demo board equipped with a AtMega88 and a FTL232RL.
During more than a year I could successfully program it via BASCOM and the MCS bootloader on the AtMega.
The board supports automatic programming (i.e. creating a reset). No reset switch on the board.
Since short this does not work anymore: the board does not react to the attempt to load new code.
It was kind of a gradual process: first I needed to power cycle the board to get it loading new code (unplugging and re-plugging the USB to the PC), but now it does not react at all.
For me it seems there is no RESET (the program still on chip continues running during the attempt to load).
According to the circuit diagram DTR is used to reset the chip, but strange enough in BASCOM under > Options - Programmer - MCS-loader < no setting at all was selected for the RESET option.
But I really did not change any of the options before neither did I touch any Fuse bits.
So I tried to select the software option, but no success.
Then I tried to use the DTR option - no success.
Any thoughts?
(BASCOM-AVR version : 2.0.7.6 ) |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Fri Jul 05, 2013 3:56 pm Post subject: |
|
|
try to measure dtr to see if it works and the ft232rl is still functioning.
you can simply measure the RESET pin of the micro and then try the bootloader. you should see activity on the reset pin. (of course setting must be that DTR is used for reset)
when that does not work you could add a diode and a button to ground for the reset. i do assume the micro is not defective and still responds to a reset? _________________ Mark |
|
Back to top |
|
|
jwolf
Joined: 18 Jan 2013 Posts: 24
|
Posted: Sat Jul 06, 2013 9:44 pm Post subject: |
|
|
thanks for the useful hints.
I will test it and report back. |
|
Back to top |
|
|
jwolf
Joined: 18 Jan 2013 Posts: 24
|
Posted: Sun Jul 07, 2013 10:07 am Post subject: |
|
|
Here is the proposed update:
1) selecting DTR for reset does the job, the s/w on the chip is clearly stopped and a reset is done
2) with the scope I can clearly see a) the reset signal and b) the repeated signal sent from the PC when trying to program
3) on the Rx (towards PC) I do not see any signal change at all, signal remains High
From what I understand from reading the MCS bootloader sourcecode - the bootloader should send some characters towards the PC as well [chr(bstatus)].
I have the impression that the micro takes much shorter time now between Reset and starting the program. Now it is about 3 sec, but I did not measure what it was before.
So I fear I have to get an ISP programmer, adapt it to the board (no ISP I/F foreseen on the PCB) and figure out how to inhibit the FT232R chip.
Cheers,
Johannes |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Sun Jul 07, 2013 10:41 am Post subject: |
|
|
and i assume you use the proper baud rate?
you can connect an isp programmer. i did so once by inserting cables at the proper locations. the question is : is the ftdi chip defect or the chip.
i would assume the chip. pity is that they used an SMD chip which is harder to replace.
one other thing : is the chip connected to other electronics ? try to remove all connections. or at least any load. And 5V from USB is still ok? _________________ Mark |
|
Back to top |
|
|
jwolf
Joined: 18 Jan 2013 Posts: 24
|
Posted: Sun Jul 07, 2013 3:32 pm Post subject: |
|
|
19200 baud rate, checked
I am rather sure the FTDI chip is OK, because I could communicate and read it using the MProg tool
also it sends data to the micro and it provides the reset signal
Yes, there is other h/w connected
I will try and disconnect it
Power is rather at the low side (4.9V), they use 10 Ohm resistors as fuse.
Best regards,
Johannes |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Sun Jul 07, 2013 8:19 pm Post subject: |
|
|
either the connected electronics causes the problem which is a bit unlikely when using a serial boot loader, but still it is possible.
more likely is that the reset of the electronics draws too much current from the bus or that the processor is defective. _________________ Mark |
|
Back to top |
|
|
jwolf
Joined: 18 Jan 2013 Posts: 24
|
Posted: Mon Jul 08, 2013 7:31 am Post subject: |
|
|
I tried disconnecting ALL other h/w - no success.
Since the micro seems to properly execute the last program I loaded, it seems not completely damaged.
What I could think of is a corrupted address pointing to the boot loader so that at the end the micro does not jump to the correct address,
but it almost immediately starts executing my program.
Next step is I have to get a programmer and try to get access to the micro and check / reload the boot loader.
Best regards,
Johannes |
|
Back to top |
|
|
JC
Joined: 15 Dec 2007 Posts: 584 Location: Cleveland, OH
|
Posted: Tue Jul 09, 2013 1:31 am Post subject: |
|
|
You did not ask, but I'll mention it anyway.
One can get a USBAsp programmer on eBay for about $3 USD. There are several Threads on the AVRFreaks Forum about the software used to drive it.
The cheap ones are shipped from China, however, so you might have to wait a while for it to be delivered.
The Atmel AVRISP mkII will program just about all of the AVRs, comes with a plastic case and a USB cable, and works well.
It is more expensive, however, about $30 USD.
JC |
|
Back to top |
|
|
jwolf
Joined: 18 Jan 2013 Posts: 24
|
Posted: Wed Jul 24, 2013 5:32 pm Post subject: |
|
|
Finally I got an USB ISP programmer and adapted it to the board (this was easier than I thought because all the signals needed are available on the IC sockets).
With the ISP programmer I could communicate with the Micro and finally flash the bootloader successfully.
I also checked the fuse and lock - Bits and they were still OK.
Switching back to using the bootloader - it works fine now.
Still I do have no idea how this could happen: was it that the application s/w tried to write accidentally into the bootloader area?
Thanks for the tips and hints.
Best regards,
Johannes |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5913 Location: Holland
|
Posted: Wed Jul 24, 2013 8:04 pm Post subject: |
|
|
i do not know which version of the bootloader was used in your product.
but early version do not protect against overwriting the boot area.
later versions have :
Code: | If Page < Maxpages Then 'only if we are not erasing the bootspace
Page = Page + 1 'next page
Spmcrval = 3 : Gosub Do_spm ' erase next page
Spmcrval = 17 : Gosub Do_spm ' re-enable page
Else
Portd.7 = 0 : Waitms 200
End If
End If
|
here the number of pages is checked and it is not possible to erase too many pages. but it could be something else as well.
i have seen chips with damages flash that worked fine after reloading the firmware. _________________ Mark |
|
Back to top |
|
|
|