Show Posts
Pages: 1 2 [3] 4 5 ... 7
31  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 03, 2013, 01:46:26 pm
Huh.  How do you even GET trailing 0xFFs in the .data segment?
I'm always getting .data from the Arduino libraries beyond everything I put in the user area of the sketch.

Libraries?

008001be d _ZL8mystdout
00800200 D trailff_RAM               ;; structure with trailing FFs
00800280 V _ZTV14HardwareSerial      ;; structure from libraries.
00800290 B __bss_start
00800290 D __data_end


im not sure i understand the question, but if i do this:

Code:
int buff[8] = {0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff, 0xffff};

void setup() {}

void loop() {
  for (int i = 0; i < 8; i++) {
    PORTD = buff[i];
  }
}

i get this:

Code:
sketch_aug03a.cpp.elf:     file format elf32-avr

Contents of section .data:
 800100 ffffffff ffffffff ffffffff ffffffff

which is put at the end of the .hex file

Code:
// top snipped off
:1001D000816080838081806880831092C10008954F
:0401E000F894FFCFC1
:1001E400FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1B
:00000001FF
32  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 03, 2013, 01:39:07 pm

Couldn't you put a dummy section at the end of the linked image to ensure that this never happened?
Yeah, it would require a tweak to the Arduino team controlled code but it's a one time thing.

that would probably work.  i am essentially doing that manually with my code by adding a single, non-FF variable after all the FF ones.
33  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 03, 2013, 01:07:38 pm
If it is ONLY the block at the very end of the sketch, that's a much less serious problem.  IMO.


this definitely means it will effect fewer people, but also means it will be far more confusing when it does happen.  the partial page trailing FF's seems like an easy fix anyways.  not sure anything can be done on the optiboot side for full pages at the end of a .hex file.
34  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 03, 2013, 02:51:33 am
using progmem, and storing blocks of data in FLASH is different, and does not act the same as storing variables.  progmem puts the data block at the beginning of the code section, so it is not a set of trailing FF's, at least as far as the entire .hex file is concerned.  so entire pages, and the ends of pages with FF, will be written if they are not the last section of the .hex file.  variables are written to the end of the .hex file, and full pages and the ends of pages will FF will not be written.
35  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 02, 2013, 11:16:15 pm
the datasheet for the atmega328 does suggest not writing blocks which are FF

Quote
Considerations for Efficient Programming
The loaded command and address are retained in the device during programming. For efficient
programming, the following should be considered.
• The command needs only be loaded once when writing or reading multiple memory locations.
• Skip writing the data value 0xFF, that is the contents of the entire EEPROM (unless the
EESAVE Fuse is programmed) and Flash after a Chip Erase.

granted, it doesnt say for just page erases, but FLASH only works by being set to FF when erased. this is why it needs to be erased, and not just written.  writing can only chang a 1 to a 0.
36  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 02, 2013, 02:40:05 pm
also, i just verified that AVRdude does NOT send full pages of FF to the arduino, when they are present in the .hex file.
37  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 02, 2013, 01:56:25 pm
haha..

what does this mean to us 'noobs' here?

I have used Optiboot to flash to chips... but I wouldnt have a clue about switches, compiling, looking under the hood.. 

Does any of this concern the 'normal' (beginner) members around here?



its a pretty rare occurance that it causes a problem, so probably not a big worry.  it happens when the last variables you define are FF.

here is an alternate fix, that i will compile and test out when i get a second, probably tomorrow.  but if anyone sees any glaring errors with it, feel free to point them out.  i define "ch" earliear as "length/2" so it can be use for the page writes.

Code:
    /* Write memory, length is big endian and is in bytes */
    else if(ch == STK_PROG_PAGE) {
      // PROGRAM PAGE - we support flash programming only, not EEPROM
      uint8_t *bufPtr;
      uint16_t addrPtr;

      getch(); /* getlen() */
      length = getch();
      ch = length / 2;  // save a copy for page writing down below
      getch();

      // If we are in RWW section, immediately start page erase
      if (address < NRWWSTART) __boot_page_erase_short((uint16_t)(void*)address);

      // While that is going on, read in page contents
      bufPtr = buff;
      do *bufPtr++ = getch();
      while (--length);

      // If we are in NRWW section, page erase has to be delayed until now.
      // Todo: Take RAMPZ into account
      if (address >= NRWWSTART) __boot_page_erase_short((uint16_t)(void*)address);

      // Read command terminator, start reply
      verifySpace();

      // If only a partial page is to be programmed, the erase might not be complete.
      // So check that here
      boot_spm_busy_wait();

#ifdef VIRTUAL_BOOT_PARTITION
      if ((uint16_t)(void*)address == 0) {
        // This is the reset vector page. We need to live-patch the code so the
        // bootloader runs.
        //
        // Move RESET vector to WDT vector
        uint16_t vect = buff[0] | (buff[1]<<8);
        rstVect = vect;
        wdtVect = buff[8] | (buff[9]<<8);
        vect -= 4; // Instruction is a relative jump (rjmp), so recalculate.
        buff[8] = vect & 0xff;
        buff[9] = vect >> 8;

        // Add jump to bootloader at RESET vector
        buff[0] = 0x7f;
        buff[1] = 0xce; // rjmp 0x1d00 instruction
      }
#endif

      // Copy buffer into programming buffer
      bufPtr = buff;
      addrPtr = (uint16_t)(void*)address;
 //     ch = SPM_PAGESIZE / 2; // ch redefined up above for new boundary size
      do {
        uint16_t a;
        a = *bufPtr++;
        a |= (*bufPtr++) << 8;
        __boot_page_fill_short((uint16_t)(void*)addrPtr,a);
        addrPtr += 2;
      } while (--ch);

      // Write from programming buffer
      __boot_page_write_short((uint16_t)(void*)address);
      boot_spm_busy_wait();

#if defined(RWWSRE)
      // Reenable read access to flash
      boot_rww_enable();
#endif

38  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 01, 2013, 12:49:11 pm
so it looks like this has been known about for a while, and that there isnt a solution that will work for all cases.  the "entire page of FF" case is particularly tricky.

i would agree that its a problem with AVRdude.  does AVRdude have a switch for sending all the bytes?  im not too familiar with AVRdude.  but, it seems like there isnt a downside to at least writing the remaining page of memory with FF (or leaving it unwritten as FF). it has already been erased, so there is no old code to save anymore, and putting what amounts to random bytes in is less predictable than just leaving FF (and takes marginally longer).
39  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 01, 2013, 02:46:48 am
how does one contact a moderator, or know which moderator to contact?  there sure are a lot of subforums around here.

also, even though its unknown how many FF's have been trimmed, filling up the remaining space with FF (or leaving it FF as the case is), is way safer then just rewriting the trailing info from the last page.
40  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 01, 2013, 02:26:20 am
i realized there was a more appropriate forum for this post, and reposted there.  feel free to delete this one.
41  Using Arduino / Audio / new arduino stompbox kit on: August 01, 2013, 02:16:41 am
i just finished a guitar effects pedal kit for arduino:
http://www.openmusiclabs.com/projects/stomp-shield/

all the plans and code are up on the wiki if you want to build your own:
http://wiki.openmusiclabs.com/wiki/StompShield

it uses the onboard ADC and PWM to do the audio in/out, but doesn't sound half bad.  i would say medium-fi.  10b/32ksps in, and 16b/32ksps out.  it also has 3-pole anti-aliasing filters on the in and out, which helps a bunch.  there are a handful of examples in the library, but there is definitely more that can be done with it.
42  Using Arduino / Microcontrollers / bug in optiboot bootloader on: August 01, 2013, 01:56:56 am
i posted this in the programming forum earlier today, as a continuation of another problem, but thought it might be helpful to start another thread specifically about this issue here.  basically, AVRdude optimizes page writes by eliminating trailing FF's (as any page should be cleared to FF before writing).  But, the optiboot bootloader writes a full page, regardless of the actual page length.  here is the code from optiboot.c:

Code:
    else if(ch == STK_PROG_PAGE) {
      // PROGRAM PAGE - we support flash programming only, not EEPROM
      uint8_t *bufPtr;
      uint16_t addrPtr;

      getch(); /* getlen() */
      length = getch();
      getch();

      // If we are in RWW section, immediately start page erase
      if (address < NRWWSTART) __boot_page_erase_short((uint16_t)(void*)address);

      // While that is going on, read in page contents
      bufPtr = buff;
      do *bufPtr++ = getch();
      while (--length);

      // If we are in NRWW section, page erase has to be delayed until now.
      // Todo: Take RAMPZ into account
      if (address >= NRWWSTART) __boot_page_erase_short((uint16_t)(void*)address);

      // Read command terminator, start reply
      verifySpace();

      // If only a partial page is to be programmed, the erase might not be complete.
      // So check that here
      boot_spm_busy_wait();

ths is the section where it writes a temporary buffer with the incoming data.  it checks the length of data in the block ("length"), and only writes "length" bytes to the temporary buffer.  in the next section, where it writes the temporary buffer to FLASH, it writes the whole buffer (SPM_PAGESIZE/2):

Code:
      // Copy buffer into programming buffer
      bufPtr = buff;
      addrPtr = (uint16_t)(void*)address;
      ch = SPM_PAGESIZE / 2;
      do {
        uint16_t a;
        a = *bufPtr++;
        a |= (*bufPtr++) << 8;
        __boot_page_fill_short((uint16_t)(void*)addrPtr,a);
        addrPtr += 2;
      } while (--ch);

so if the last few lines of a partial page write have FF in them, they will actually get written with the ending contents of the previous page.  this is an unlikely scenario (the last few bytes being FF), but occurs when you declare a variable or variables to FF, and they are the last variable(s) you declare.  a work-around is to make sure the last variable you declare is not FF, or re-initialize your FF variables in setup().  as for the bootloader, probably the best fix is to only write "length" bytes from the temporary buffer to the FLASH.
43  Using Arduino / Audio / Re: Need help identifying an amplifier on: July 31, 2013, 06:47:34 pm
awesome.  c20 is the input.  just cut the trace, and solder to the end of c20 facing away from the chip.
44  Using Arduino / Programming Questions / Re: bug with declaring a variable on: July 31, 2013, 06:44:48 pm
i found the problem here.  AVRdude optimizes trailing FF's out of its transfer, as any block needs to be erased (set to FF) before being written.  but, it seems the bootloader on the UNO does NOT clear its temporary buffer to FF, and therefore writes that last content that was there, rather than FF as it should.  the duemilanove bootloader clears the buffer appropriately.

so, if any of the last variables you declare are 0xFFFF (bytes will work here, but ints and longs will not), they will not get written appropriately.
45  Using Arduino / Audio / Re: Need help identifying an amplifier on: July 31, 2013, 05:11:32 pm
oops, i meant c20.

you can try sending the signal in there.  just cut the trace thats coming from dual pot.  what is the part number on u8.  that might help figure out if its actually the amp chip, and which pins are which.
Pages: 1 2 [3] 4 5 ... 7