#avr Logs

Mar 18 2021

12:19 AM rue_mohr: so, the embedded bootloader, with no serial flow control, cant properly write the flash when you send the data as fast as you can?
12:26 AM rue_mohr: cause your, as everyone does, using the highest baud rate you can configure it to?
01:17 AM captain_morgan6 is now known as captain_morgan
06:08 AM exp: rue_mohr: I just use avrdude, but it's a consistent boundary on 0x8000
06:09 AM exp: I have had many flash failures but I do two verify stages to ensure it's good, in this case it's never good
06:13 AM LeoNerd: A flash failure at the 0x8000 boundary really does sound like a bank-switching problem to me
06:32 AM exp: LeoNerd: yeah it would make sense, but I found absolutely nothing in the datasheet
06:32 AM exp: LeoNerd: could you suggest what I should be looking for?
06:33 AM LeoNerd: What chip?
06:34 AM exp: AT90USB646
06:38 AM LeoNerd: Oh also, what about lock bits? Maybe some combination of those forbids writing in that area?
06:45 AM exp: LeoNerd: yeah I thought that, I set the LOCKBITS to 0xff and tried setting it manually too
06:45 AM exp: but I've yet to dump them from running firmware
06:45 AM LeoNerd: Well, in any case this isn't a chip I'm familiar with, so I can only give some general vague thoughts
06:51 AM exp: LeoNerd: still much appreciated
06:51 AM exp: I also have very little experience :)
07:57 AM exp: LeoNerd: I've checked the result of boot_lock_fuse_bits_get(GET_LOCK_BITS) and it's 0xFF as expected, so nothing should be locked
11:56 AM twnqx: 0x8000 words make sense as that's 64k...
11:57 AM exp: twnqx: yeah I checked that and avrdude is very insistent it's bytes, and the usb log shows it sending 0x4080
11:57 AM exp: I guarantee it's failing once my code goes over 32768 too :)
11:58 AM exp: so I don't think it's the classic words/bytes mistake, but that's all I could find on Google :)
11:58 AM twnqx: flash a dfu or avr109 bootloader and use that? :P
11:59 AM exp: this is an avr109 bootloader
12:00 PM LeoNerd: Can avr109 cope with >64Ki images?
12:00 PM LeoNerd: It might just be a fundamental limitation of the protocol
12:00 PM twnqx: the issue is between 32k and 64k
12:00 PM exp: LeoNerd: it uses a u32 for the size and uses avr-gcc's standard utils without any special handling, and this is 32k
12:01 PM LeoNerd: The size in bytes, or words?
12:01 PM twnqx: bytes
12:01 PM exp: sorry for brief reply, on a meeting. This is the BootloaderCDC project from LUFA with effectively zero modifications
12:01 PM exp: LeoNerd: words
12:01 PM * LeoNerd willing to bet someone has screwed up with a signed s16 somewhere along the lines
12:01 PM exp: I couldn't find anywhere they have offhand, but I don't have a board with JTAG set up so I don't know how best to continue to debug this
12:02 PM twnqx: try to find the dfu bootloader from microchip and use that :P
12:03 PM twnqx: https://ww1.microchip.com/downloads/en/DeviceDoc/megaUSB_DFU_Bootloaders.zip
12:03 PM exp: I can't use a stock one as I need to ensure there's custom pins set in the bootloader, heh
12:03 PM exp: for now my solution is to keep my code smaller than 32k
12:03 PM exp: and i'll put a 1287 on the next board I build
12:04 PM exp: it's such a specific issue though I'm surprised I can't find it on Google. I may be doing something dumb, will double check I diff against BootloaderCDC too
12:09 PM twnqx: also check where you located the bootloader. if it's sitting right at 0x8000 it won't allow you to selfdestruct it :P
12:14 PM exp: twnqx: max flash size is 8k i believe (4k words), so it should be 56k in
12:14 PM exp: uh, max boot size*
12:16 PM twnqx: what does avr-objdump -f BootloaderCDC.elf say?
12:17 PM exp: start address 0x0000e000
12:17 PM exp: i assume that's the line you care about?
12:18 PM twnqx: yes
12:18 PM twnqx: so it should be fine
04:50 PM [1]MrMobius is now known as MrMobius