ea / srxe_cc1101

Adding a CC1101 module to SRXE
118 stars 13 forks source link

AVRDUDE #10

Closed ea3iav closed 3 years ago

ea3iav commented 4 years ago

Hello! I just got a couple of SmartResponse XE devices and I was trying to flash the bootloader. I have the USBASP and all wiring but I am unable to make de Avrdude command to work

`/bin/avrdude -C/etc/avrdude.conf -v -patmega128rfa1 -cusbasp -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0xF5:m -Uhfuse:w:0xD8:m -Ulfuse:w:0xFF:m

/bin/avrdude -C/etc/avrdude.conf -v -patmega128rfa1 -cusbasp -Pusb -Uflash:w:./SMART_bootloader/ATmegaBOOT_atmega128rfa1.hex:i -Ulock:w:0x0F:m`

I get System can't find route

Where am I supposed to put the hex file? I mean In which directory? I have installed WINAVR but there is no ETC folder

Thank you!

ea commented 4 years ago

the path to the hex file is in the '-Uflash:w:' parameter. In my example , the path is "./SMART_bootloader/ATmegaBOOT_atmega128rfa1.hex" , replace that with your path to the hex file.

ea3iav commented 4 years ago

Thank you! Is there a way to use the gui interface of Avrdudess. I tried that using your fuse settings and lock. It showed that it was fine, but the unit doesn't boot usbasp

The console showed this:


>>>: avrdude -u -c usbasp -P COM1 -B 0.5 -p m8 
Detected 1ea701 = ATmega128RFA1
Reading fuses...
>>>: avrdude -u -c usbasp -p m128rfa1 -P COM1 -B 0.5 -U hfuse:r:-:h -U lfuse:r:-:h -U efuse:r:-:h 
SUCCESS: Read high fuse
SUCCESS: Read low fuse
SUCCESS: Read extended fuse
Reading lock bits...
>>>: avrdude -u -c usbasp -p m128rfa1 -P COM1 -B 0.5 -U lock:r:-:h 
SUCCESS: Read lock bits
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
>>>: avrdude -u -c usbasp -p m128rfa1 -P COM1 -B 0.5 -U flash:w:"C:\WinAVR\ATmegaBOOT_atmega128rfa1.hex":a -U lfuse:w:0xEE:m -U hfuse:w:0x92:m -U efuse:w:0xFC:m -U lock:w:0x0C:m 

avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1ea701 (probably m128rfa1)
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: reading input file "C:\WinAVR\ATmegaBOOT_atmega128rfa1.hex"
avrdude.exe: input file C:\WinAVR\ATmegaBOOT_atmega128rfa1.hex auto detected as raw binary
avrdude.exe: writing flash (131072 bytes):

Writing | ################################################## | 100% 130.60s

avrdude.exe: 131072 bytes of flash written
avrdude.exe: verifying flash memory against C:\WinAVR\ATmegaBOOT_atmega128rfa1.hex:
avrdude.exe: load data flash data from input file C:\WinAVR\ATmegaBOOT_atmega128rfa1.hex:
avrdude.exe: input file C:\WinAVR\ATmegaBOOT_atmega128rfa1.hex auto detected as raw binary
avrdude.exe: input file C:\WinAVR\ATmegaBOOT_atmega128rfa1.hex contains 131072 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 67.61s

avrdude.exe: verifying ...
avrdude.exe: 131072 bytes of flash verified
avrdude.exe: reading input file "0xEE"
avrdude.exe: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xEE:
avrdude.exe: load data lfuse data from input file 0xEE:
avrdude.exe: input file 0xEE contains 1 bytes
avrdude.exe: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe: reading input file "0x92"
avrdude.exe: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude.exe: 1 bytes of hfuse written
avrdude.exe: verifying hfuse memory against 0x92:
avrdude.exe: load data hfuse data from input file 0x92:
avrdude.exe: input file 0x92 contains 1 bytes
avrdude.exe: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of hfuse verified
avrdude.exe: reading input file "0xFC"
avrdude.exe: writing efuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude.exe: 1 bytes of efuse written
avrdude.exe: verifying efuse memory against 0xFC:
avrdude.exe: load data efuse data from input file 0xFC:
avrdude.exe: input file 0xFC contains 1 bytes
avrdude.exe: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of efuse verified
avrdude.exe: reading input file "0x0C"
avrdude.exe: writing lock (1 bytes):

Writing | ################################################## | 100% 0.01s

avrdude.exe: 1 bytes of lock written
avrdude.exe: verifying lock memory against 0x0C:
avrdude.exe: load data lock data from input file 0x0C:
avrdude.exe: input file 0x0C contains 1 bytes
avrdude.exe: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lock verified

avrdude.exe done.  Thank you.

``

ea3iav commented 4 years ago

How do I know I didn’t brick it?

bubbadestroy commented 4 years ago

I was just thinking of giving this a go and hoped that maybe the community had picked up again for seeing what else can be done to these things, have an array of toys for atmel now.

ea3iav commented 4 years ago

If only I could get this working... I am trying to follow instructions but they sre so fragmented

bubbadestroy commented 4 years ago

//I'm fairly amateur at that part of the game yet. I break shit a lot, but I have a hard time giving up till its destroyed or I figure out //how I could have not destroyed ----

//A few troubleshooting techniques come to mind. //And the steps I take to debug are all over the place so, I apologize if you find the answer being the last suggestion in the //following (random) order.

  1. Troubleshoot / Make an Assessment

'Here's what i noticed. from your logs.'

avrdude.exe: set SCK frequency to 1500000 Hz avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update. avrdude.exe: AVR device initialized and ready to accept instructions

'Updating the usbasp firmware if possible may help., on the other-hand it could need to be at a certain version to correctly flash to its target' & _Double check that the target you are flashing too hasn't run out of memory? usbasp is updated right? everytthings updated, drivers, windows update. pkg update. did you update your family that you will be busy tonight messing with embedded linux_?

Probably doesn't apply if you are going right off the guide however..

ea said

You can also get away with using any random arduino board you have laying around (search for arduino ISP guide).

Nice thing about Larry's bootloader is that it gives us 3 ways of flashing firmware to the SRXE. Over either of the two existing serial interfaces or over wireless! There's quite a bit of code involved in doing it wirelessly, which takes away from space available to the rest of the code, so at some point we might want to slim down the bootloader and keep only the serial way if needed.

otherwise I suggest seeing about flashing firmware from a different environment check below for various links to try different approaches / environments.

  1. debug

**If that's not an issue, or an option than I suggest an experiment.

Flash firmware on another ATMEGA chip _Reason: if it suceeds letting you use your usbasp programmer to flash flash onto another board using atmel avr then you know that all the above steps are not the problem, except for the problem which is a problem of an array of problems of itself being the only conditional problem else_

  1. Rinse&Repeat. Troubleshiiiiiiiit until you 💩 🥇

    speaking of - reading that gave me that idea. I checked sources and maybe if they don't hold a direct method that works for your problem; you may find looking into them they hold something that will spark your 🧷 🔢 🧼 solution..

The guy who made the boot-loader you're going to flash: https://bitbanksoftware.blogspot.com/2018/09/my-adventures-in-writing-ota-bootloader.html

Some random tutorial that kept popping up as I looked into this further. https://www.elecrom.com/avrdude-tutorial-burning-hex-files-using-usbasp-and-avrdude/

Some old tutorials that had mention of something you might find interesting, something besides avrdude.

Burn the firmware by AVRdude or by PonyProg

https://puranranablog.blogspot.com/2011/05/diyavr-programmerponyprog.html

https://www.circuitsdiy.com/simplest-usb-avr-programmer/

last but not least.

https://en.wikipedia.org/wiki/AVR_microcontrollers#Programming_interfaces

ok really last . have u tried from linux? vscode?

https://dev.to/derkoe/development-environment-in-wsl2-137l

then something like should still apply

https://skjoldtech.wordpress.com/2019/05/10/flashing-arduino-hex-file-in-linux-with-avrdude/

my method...

--linux stuff that i barely understand but usually works

dmesg -wH from a second terminal / powershell while the primary is hitting it with avrdude script. should tell you whats happening during flash in human readable detail..

Check that the target you are flashing too hasn't run out of memory

  1. debug the environmen/t lab xxxxxx00x0x0x0x0x0x0x0xx0x00x0xx00x001210 _ halt_errorreboot
ea commented 4 years ago

I really don't know what else i could add. After flashing the boot loader (which seems to have succeeded in your console output) , putting the batteries back in should boot the device into boot loader and you should see it on the screen.