Show Posts
Pages: 1 2 [3] 4 5 ... 7
31  Using Arduino / Audio / Re: Strange behavior with power supply vs. computer USB power on: August 09, 2013, 03:25:56 am
when you plug your arduino into the USB on your computer, you are doing 2 things: 1. giving it 5V power, 2. connecting it to a device that it can talk to.  your code is most likely trying to talk to the computer, and when there is no computer connected, it fails, and the program hangs.
32  Using Arduino / Audio / Re: Strange behavior with power supply vs. computer USB power on: August 07, 2013, 11:14:23 pm
sounds like a code thing.  can you post your code, and which versions of libraries you might be using.
33  Using Arduino / Audio / Re: Strange behavior with power supply vs. computer USB power on: August 06, 2013, 08:37:37 pm
do you have something that supplies 5v over a usb cable?  like a small charger?  if that worked, it would rule out the powersupply question.  its more like a code thing, like hanging on a serial.available() or something
34  Using Arduino / Audio / Re: Storing data in an audio channel on: August 05, 2013, 06:56:32 pm
the data rate you will get will depend upon the lock time of the PLL (XR2211).  this is typically set the by the lowpass filter time constant on the output filter, which is usually pretty slow.  a better estimate would probably be closer to 250bps.  always makes me impressed with 56kbps telephone modems.  also, why is the audio bandwidth of the recorder so low?  im assuming the 3kHz is the max frequency it can accept, and not the sampling rate, which means you can go higher than 1.5kHz (all the way to 3kHz).
35  Using Arduino / Audio / Re: Storing data in an audio channel on: August 05, 2013, 02:08:47 pm
the XR2206 is an awesome chip.  but you can probably just generate the tones with the tone() library.  what is your plan for decoding?  if you need a higher data rate you might be able to send a series of different tones, each representing a different value.
36  Using Arduino / Microcontrollers / Re: bug in optiboot bootloader on: August 03, 2013, 01:54:28 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.

another nice thing about this method, is that people could just update their arduino ide, rather than burning a new bootloader.
37  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
38  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.
39  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.
40  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.
41  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.
42  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.
43  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

44  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).
45  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.
Pages: 1 2 [3] 4 5 ... 7