Back
[00:00:15] <gorroth> if i have the avr input a small delay before it tries writing both bytes, then all is fine
[00:00:31] <gorroth> like i have it write the first byte, then delay 100ms, then write the second byte, all is well
[00:00:52] <gorroth> i thought my code that loops would prevent that from happening, but maybe it's that bit shift issue FrankD was talking about
[00:03:00] <FrankD> PC has a relatively big hardware FIFO on top of whatever is implemented in software
[00:04:59] <gorroth> yeah, but the PC isn't the problem
[00:05:18] <gorroth> if i send two bytes back-to-back in the AVR with no delay, it seems my second byte gets corrupted
[00:05:40] <gorroth> which, i don't know why, because my uart0_transmit() function has a loop that checks if UDRE0 bit is set or not
[00:05:43] <FrankD> thats strange
[00:08:22] <gorroth> even added a check to see that TXC0 is not set and took out my delay between the sends. still had the problem. hmm, oh well
[00:11:05] <gorroth> 1ms delay was enough to resolve the issue. i'll just go with that for the time being to get past this stage of progresss and come back to it after i get the bootloader working
[00:11:14] <gorroth> thanks all for the help, and now i really WILL sleep
[00:15:43] <FrankD> night man, glad you got it to work even if its a little hacky
[00:15:45] <FrankD> :)
[00:15:49] <FrankD> gg
[09:58:59] <gorroth> well, i thought my bootloader was writing data to the right locations, but even avrdude is saying there's a content mismatch when i use it to verify my hex file against the device (for the non-bootloader section)
[09:59:35] <gorroth> avrdude: verification error, first mismatch at byte 0x0000 0xff != 0x0c
[09:59:48] * gorroth grumbles a little
[10:00:18] <gorroth> my bootloader, however, gladly echoes back what it receives, as if it is doing something with it, and the crc for that line of data is correct
[10:00:27] <gorroth> i mean, from the bootloader's perspective
[10:00:32] <gorroth> it must not be writing the page properly
[10:02:31] <RikusW> it is somewhat tricky to get it right...
[10:02:49] <RikusW> did you set the pointer to start of page before writing ?
[10:03:38] <Lambda_Aurigae> and erase the page first!
[10:05:04] <gorroth> RikusW: i assume you mean set an address (in libc-avr, we just use a uint16_t to record the word-aligned byte address). yes, i definitely did do that. i have a formula that calculates the base address of pages
[10:05:09] <gorroth> Lambda_Aurigae: yes, absolutely
[10:05:10] <osteri> some version of avrdude actually didn't work with USBtiny, i don't know if it is fixed or not, i'm using older avrdude 5.9 because of that
[10:05:45] * RikusW did an asm stk500v2 bootloader
[10:06:06] * gorroth did not
[10:06:23] <gorroth> the datasheets for things like that were not good, imo, or maybe i couldn't find the good ones
[10:07:59] <osteri> gorroth: what kind of solution you ended up with your BL, existing protocol?
[10:09:08] <gorroth> no
[10:09:29] <gorroth> i just receive binary data over uart and write to the proper locations
[10:10:08] <gorroth> given address X, i calculate the page base using X & ~(SPM_PAGESIZE-1), which is correct
[10:11:26] <gorroth> osteri: my protocol is very simple: send 'L' and then the byte for length, send 'A' and then two bytes for the address, send 'D' and then L bytes for data, send 'E' to end bootloader and jump to address 0x00
[10:11:55] <gorroth> osteri: my bootloader also returns some basic data for each of those. mostly just echoes data back, but for 'D' in particular, it returns the CRC it's been computing
[10:15:49] <osteri> gorroth: yeah, i was thinking of using existing protocol (for e.g AVR109) and just write a new handler to avrdude, so you could use avrdude for flashing
[10:16:09] <gorroth> same here, and then the existing code out there didn't work
[10:16:17] <gorroth> and my protocol is simpler; so, i'm just going with it for now
[10:16:30] <gorroth> i didn't feel like debugging the other code when my own was pretty close
[10:17:23] <osteri> but if you use different interface (other than serial) with custom AVR, you'd still have to write bootloader
[10:17:33] <osteri> AVR=avrdude
[10:17:37] <gorroth> btw, i think i might have found the problem
[10:17:55] <Tom_itx> wastes bytes with that protocol
[10:18:34] <gorroth> yeah, avr109 also looked like it did a ton of stuff i don't care about, which is another reason i went with mine
[10:42:10] <RikusW> stk500v2 is pretty nice to use
[11:07:22] <ali1234> is there an open source board that does USB to JTAG based around AVR?
[11:07:39] <ali1234> when i try to google it, I just get results about using JTAG to debug AVR, which is not what I want
[11:10:18] <ali1234> nvm i found one:
https://code.google.com/p/opendous-jtag/
[11:35:27] <gorroth> i'm lost..
[11:35:39] <gorroth> i've broken the code down into the smallest thing that should work and pasted it to
http://pastebin.com/csU3J9rZ
[11:35:43] <Lambda_Aurigae> gorroth, don't forget word vs byte addressing.
[11:35:47] <gorroth> i know
[11:36:06] <gorroth> that "code" array is a basic "blink/hello world" kind of app
[11:36:24] <Lambda_Aurigae> have you looked at other bootloaders to see how they do it?
[11:36:25] <gorroth> but when i do the jump to address 0x0000, it just goes right back into the bootloader
[11:36:30] <Lambda_Aurigae> oh
[11:36:32] <Lambda_Aurigae> that's normal.
[11:36:37] <gorroth> that is normal?
[11:36:41] <Lambda_Aurigae> your bootloader has to have a way to init or not init.
[11:36:53] <Lambda_Aurigae> usually it's a timeout or a pin held low or high or something.
[11:37:01] <gorroth> no, have you looked at my code
[11:37:26] <Lambda_Aurigae> if the bootloader doesn't get a start command in a certain amount of time then it jumps to code start.
[11:37:34] <Lambda_Aurigae> although, I think 0x0000 should be right.
[11:37:53] <gorroth> no, that is if you're trying to have some other piece of software load onto it
[11:37:55] <Lambda_Aurigae> have you tried writing your program via avrdude and a direct programmer and seeing if it works?
[11:37:57] <gorroth> this isn't even reading uart anymore
[11:37:59] <gorroth> have you read my code?
[11:38:09] <Lambda_Aurigae> no
[11:38:14] <gorroth> that would help :)
[11:38:31] <Lambda_Aurigae> I am reading 3 other PDF files at the moment and about to go out on a little trip.
[11:38:53] <Lambda_Aurigae> from which I should return sometime late tomorrow.
[11:38:56] <gorroth> i know my other program works; it's been done with avrdude
[11:39:02] <gorroth> i know all these things people are saying
[11:39:10] <gorroth> so i think something is just messed up in my code that i can't see
[11:39:16] <gorroth> hopeing someone can read my paste
[11:39:22] <gorroth> http://pastebin.com/csU3J9rZ for those that missed it
[12:26:16] <ali1234> gorroth: what is it supposed to do?
[12:29:27] <ali1234> that for loop looks mighty suspicious
[12:30:09] <ali1234> page_base_addr = PAGE_BASE(addr); .... if (PAGE_BASE(addr) != page_base_addr)
[12:30:37] <ali1234> so under initial conditions, that code will not run
[12:31:05] <ali1234> now addr is incremented by the for loop, but only after you've been around the loop once
[12:32:08] <ali1234> conclusion: the first page never gets written
[12:32:39] <ali1234> so how big is a page size? if it's bigger than 164 bytes... this code does nothing
[12:34:33] <ali1234> also "i < sizeof(code)/sizeof(uint8_t)" looks suspicious
[12:41:01] <ali1234> wait, i see how it's supposed to work now
[16:56:12] <gorroth> ali1234: the loop will run as long as it's reading code[]. flash_write_page will be called when we move from one page to the next. the last page will be missed; therwfore, there's a flash_write_page call after the loop
[16:57:18] <gorroth> and my bootloader is written to address 0x3C00, afaik. that's what the ihex has anyway, which lines up with where i put the bootloader start address
[16:57:35] <gorroth> and, well, as i've seen, it does actually get into the bootloader, but it gets in there whether or not i set BOOTRST FUSE BIT
[17:12:39] <ali1234> if the rest of the pages are blank, then it will eventually end up in the bootloader
[17:16:28] <antto> a few NOPs later..
[17:18:02] <gorroth> as you can see, the pages at address 0x0000 up to 164 bytes later should be written with that code
[17:22:51] <ali1234> i still suspect it's something to do with sizeof()
[17:23:14] <ali1234> what happpens if you hardcode the value to 164 instead of trying to calculate it?
[17:23:36] <ali1234> my other guess is that you need to do something special to unlock the flash before you can even erase it
[17:23:43] <ali1234> possibly involving fuses
[17:24:19] <ali1234> i would remove the for loop and just try to write one page
[17:25:11] <ali1234> you've read
http://www.atmel.com/images/doc1644.pdf right?
[17:25:28] <gorroth> yes, i've read it
[17:25:48] <gorroth> can't do any writing at the moment; having network issues to my rpi
[17:26:26] <gorroth> lock bits are unprogrammed (i.e. not locked)
[17:27:22] <gorroth> unprogrammed, in terms of lock bits, means setting them high
[17:28:20] <gorroth> anyway, i'll go back, as soon as i can get back into my rpi, and write null bytes to the page at base 0x0000
[17:28:41] <gorroth> then use avrdude to see if they were written
[17:31:01] <antto> how big is the page?
[17:31:59] <gorroth> they're 64 bytes on this mcu
[17:32:07] <antto> well
[17:32:21] <antto> why do i not see a loop for pages?
[17:32:46] <gorroth> because i have more code than 64 bytes
[17:33:09] <antto> you're trying to write a 164 byte chunk of code into flash, and you only copy 64 bytes of it?
[17:33:38] <gorroth> no
[17:33:52] <gorroth> you can only work with a page at a time
[17:34:36] <gorroth> i fill a page buffer, erase the page, write the page, move to the next page, repeat
[17:34:51] <antto> okay.. so you copy the first 64 bytes of the code into a page, you write the page, and then you jump to the app
[17:35:10] <antto> or am i missing the page loop
[17:35:14] <ali1234> line 77?
[17:35:51] <gorroth> for (uint8_t i = 0; i < sizeof(code)/sizeof(uint8_t); ++i, ++addr) {
[17:36:00] <gorroth> PAGE_BASE calculates the base address of the page based on addr
[17:36:08] <gorroth> PAGE_OFFSET calculates the offset into the page i'm working on
[17:36:15] <gorroth> based on addr
[17:36:29] <antto> gorroth the "for" loop, it's scope ends on line 93, doesn't it?
[17:36:34] <antto> * its
[17:36:46] <gorroth> sizeof(code) will return the correct number of bytes. the sizeof(uint8_t) is for completeness but is not necessary for this
[17:36:54] <ali1234> flash_write_page is also called in the loop
[17:37:09] <gorroth> i know it's called in the loop
[17:37:18] <gorroth> as it should be when i cross page boundaries
[17:37:39] <gorroth> it's also called once after the loop to make sure the last page i was working on gets written
[18:27:28] <gorroth> something just completely crossed my mind. since i've taken out the code for using uart and all that, i can probably load that code directly into simavr and figure out what's going on that way
[18:27:55] <gorroth> otherwise i'll have to figure out how to hook up my AVR Dragon that i haven't used in years
[18:29:24] <gorroth> ermahgawd, it even has uart in the simavr. so i can do the whole thing that way
[20:27:39] * gorroth installs Windows 10 in a VM just to get access to first class simulators
[20:27:53] <gorroth> might have to hook up my dragon later, but i'll try in the simulator first :)
[20:35:35] <ali1234> i believe there's even a simulator with USB support
[20:39:43] <gorroth> ali1234: on windows?
[20:58:15] <ali1234> on linux for sure, probably on windows too
[20:58:32] <ali1234> also i got this jtag thing working, it's cool
[20:58:41] <ali1234> i jtagged my clock radio
[20:59:22] <ali1234> i ported opendous to a newer LUFA for atmega32u2 support