Author Topic: DualOptiboot with different flash chip..  (Read 2419 times)

englund

  • Newbie
  • *
  • Posts: 30
DualOptiboot with different flash chip..
« on: July 14, 2014, 05:51:39 PM »
Hi Felix!

I'm trying to use DualOptiboot with a different flash chip that doesn't support the 32k erase you are using so I have replaced it with a 64k erase. When compiling your original code from github everything works fine and I can program the device using
Code: [Select]
avrdude -p m328p -b 115200 -v -P /dev/ttyUSB1 -c arduino -u -U flash:w:firmware.hex
On a sidenote, when I enable debug prints by uncommenting the debug define the hex becomes to large and I have to change the Makefile to
Code: [Select]
atmega328: LDSECTIONS  = -Wl,--section-start=.text=0x7800 -Wl,--section-start=.version=0x7ffe
to allow for a bootloader greater than 1024k - did you get your debug version to 1024k or less?
Back to the main issue. Basically the only code I have changed is the value of the erase command and some ports and pins since my flash is connected differently than on the Moteino. This is the diff of all changed files
Code: [Select]
diff -rupN DualOptiboot-master/Makefile DualOptiboot-MiniWireless/Makefile
--- DualOptiboot-master/Makefile 2014-07-14 21:54:10.664702000 +0200
+++ DualOptiboot-MiniWireless/Makefile 2014-07-14 22:06:51.398213500 +0200
@@ -219,7 +219,7 @@ diecimila_isp: isp
 
 atmega328: TARGET = atmega328
 atmega328: MCU_TARGET = atmega328p
-atmega328: CFLAGS += '-DLED_START_FLASHES=3' '-DBAUD_RATE=115200' '-DLED_DATA_FLASH=1'
+atmega328: CFLAGS += '-DLED_START_FLASHES=5' '-DBAUD_RATE=115200' '-DLED_DATA_FLASH=1'
 atmega328: AVR_FREQ = 16000000L
 atmega328: LDSECTIONS  = -Wl,--section-start=.text=0x7c00 -Wl,--section-start=.version=0x7ffe
 atmega328: $(PROGRAM)_atmega328.hex
diff -rupN DualOptiboot-master/optiboot.c DualOptiboot-MiniWireless/optiboot.c
--- DualOptiboot-master/optiboot.c 2014-07-14 21:54:10.675702700 +0200
+++ DualOptiboot-MiniWireless/optiboot.c 2014-07-14 22:04:59.902836300 +0200
@@ -153,7 +153,8 @@
 /* 500,1000,2000,4000,8000 supported.                     */
 /*                                                        */
 /**********************************************************/
-
+
+
 /**********************************************************/
 /* Version Numbers!                                       */
 /*                                                        */
@@ -191,7 +192,8 @@
 asm("  .section .version\n"
     "optiboot_version:  .word " MAKEVER(OPTIBOOT_MAJVER, OPTIBOOT_MINVER) "\n"
     "  .section .text\n");
-
+
+
 #include <inttypes.h>
 #include <avr/io.h>
 #include <avr/pgmspace.h>
@@ -304,9 +306,9 @@ void appStart() __attribute__ ((naked));
 #define SPI_CLOCK_MASK 0x03  // SPR1 = bit 1, SPR0 = bit 0 on SPCR
 #define SPI_2XCLOCK_MASK 0x01  // SPI2X = bit 0 on SPSR
 #define SPI_CLOCK_DIV2 0x04
-#define FLASHSS_DDR     DDRB
-#define FLASHSS_PORT    PORTB
-#define FLASHSS         PINB0
+#define FLASHSS_DDR     DDRD
+#define FLASHSS_PORT    PORTD
+#define FLASHSS         PIND5
 #define SS              PINB2
 #define FLASH_SELECT   { FLASHSS_PORT &= ~(_BV(FLASHSS)); }
 #define FLASH_UNSELECT { FLASHSS_PORT |= _BV(FLASHSS); }
@@ -315,7 +317,9 @@ void appStart() __attribute__ ((naked));
 #define SPIFLASH_STATUSREAD       0x05        // read status register
 #define SPIFLASH_WRITEENABLE      0x06        // write enable
 #define SPIFLASH_ARRAYREADLOWFREQ 0x03        // read array (low frequency)
-#define SPIFLASH_BLOCKERASE_32K   0x52        // erase one 32K block of flash memory
+//#define SPIFLASH_BLOCKERASE_4K    0x20        // erase one 4K block of flash memory
+//#define SPIFLASH_BLOCKERASE_32K   0x52        // erase one 32K block of flash memory
+#define SPIFLASH_BLOCKERASE_64K   0xD8        // erase one 64K block of flash memory
 #define SPIFLASH_JEDECID          0x9F        // read JEDEC ID
 //#define DEBUG_ON                            // uncomment to enable Serial debugging
                                               // (will output different characters depending on which path the bootloader takes)
@@ -434,8 +438,8 @@ void CheckFlashImage() {
     putch('E');
 #endif
 
-    //erase the first 32K block where flash image resided
-    FLASH_command(SPIFLASH_BLOCKERASE_32K, 1);
+    //erase the first 64K block where flash image resided
+    FLASH_command(SPIFLASH_BLOCKERASE_64K, 1);
     SPI_transfer(0);
     SPI_transfer(0);
     SPI_transfer(0);
@@ -892,4 +896,4 @@ void appStart() {
 #endif
     "ijmp\n"
   );
-}
+}
\ No newline at end of file
diff -rupN DualOptiboot-master/pin_defs.h DualOptiboot-MiniWireless/pin_defs.h
--- DualOptiboot-master/pin_defs.h 2014-07-14 21:55:01.402164700 +0200
+++ DualOptiboot-MiniWireless/pin_defs.h 2014-07-14 21:56:28.819206000 +0200
@@ -3,7 +3,7 @@
 #define LED_DDR     DDRB
 #define LED_PORT    PORTB
 #define LED_PIN     PINB
-#define LED         PINB5
+#define LED         PINB1
 
 /* Ports for soft UART */
 #ifdef SOFT_UART
This is my gcc version
Code: [Select]
pi@raspberrypi /usr/share/arduino/hardware/arduino/bootloaders/optiboot $ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.7.2/lto-wrapper
Target: avr
Configured with: ../src/configure -v --enable-languages=c,c++ --prefix=/usr/lib --infodir=/usr/share/info --mandir=/usr/share/man --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --enable-shared --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-libssp --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=avr
Thread model: single
gcc version 4.7.2 (GCC)
But when I run the modified bootloader I cannot upload code using the same command as earlier. I get
Code: [Select]
avrdude: stk500_recv(): programmer is not responding
when using the non-debug version and
Code: [Select]
avrdude: stk500_getsync(): not in sync: resp=0x53
when using the debug version. The debug version prints out
Code: [Select]
SFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFASSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS <and continues printing S>
if I connect with a serial terminal and reset the atmega328p.

Any thoughts on this would be very much appreciated, I've been banging my head against this problem for quite a while now :(
« Last Edit: July 15, 2014, 03:00:08 AM by englund »

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6370
  • Country: us
    • LowPowerLab
Re: DualOptiboot with different flash chip..
« Reply #1 on: July 15, 2014, 08:18:40 AM »
I would check the SPI settings. Clock polarity, data transfer mode, clock speed, etc.
Other than having a much larger FLASH chip I don't see why you'd not use the stock chip I provide.
The DEBUG statements were added when I originally developed DualOptiboot based on Optiboot 4.4. They mean certain things so you should follow the bootloader code depending on where it is based on that DEBUG output.
I will release a new version soon based on v5.

englund

  • Newbie
  • *
  • Posts: 30
Re: DualOptiboot with different flash chip..
« Reply #2 on: July 16, 2014, 08:18:27 AM »
Thanks alot for the quick reply! Had a deeper look and tracked it down to the bootloader freezing at this line (the first SPI_transfer(0) in CheckFlashImage):

Code: [Select]
uint8_t deviceId = SPI_transfer(0);

So I tried copying all the SPI code from the bootloader to a .ino sketch and then it worked almost fine. It never froze but the first read after a reset returns 0 for the JEDECID while the second read returns the correct JEDECID. The third read once again returns 0 and the fourth correct data and so it continues with every other read being correct. Same thing goes for reading data from the flash. If I add

Code: [Select]
  Serial.println(FLASH_readByte(0));
  Serial.println(FLASH_readByte(1));
  Serial.println(FLASH_readByte(2));

after the JEDECID read they return random (faulty) data every other read and correct data when the JEDECID is read correctly.
Are there some hidden SPI-initializations going on that can be the cause of the code working in a sketch and not in the bootloader?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6370
  • Country: us
    • LowPowerLab
Re: DualOptiboot with different flash chip..
« Reply #3 on: July 16, 2014, 08:31:35 AM »
Not really. I think most FLASH chips have a very similar instruction set, but some might not, or might use different SPI settings. You should look at the datasheet to check the requirements for the clock speed (although all the chips I ever looked at were in the tens of Mhz at least) and if the commands match.
A logic analyzer can be your friend when debugging such issues.

englund

  • Newbie
  • *
  • Posts: 30
Re: DualOptiboot with different flash chip..
« Reply #4 on: July 16, 2014, 09:16:28 AM »
The flash chip (S25FL127S) works perfectly when using your SPIFlash-library, supports all the instructions and supports 108MHz..
Yeah, whish I had one.. :(

englund

  • Newbie
  • *
  • Posts: 30
Re: DualOptiboot with different flash chip..
« Reply #5 on: July 16, 2014, 03:19:27 PM »
I've ordered a logic analyzer now (http://www.dx.com/p/logic-analyzer-w-dupont-lines-and-usb-cable-for-scm-black-148945)
Any hints on how you would debug it? Simply record a working session and a failing one and see what differs?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6370
  • Country: us
    • LowPowerLab
Re: DualOptiboot with different flash chip..
« Reply #6 on: July 16, 2014, 05:32:57 PM »
Logic analyzing means looking at bytes of data and the datasheet and figuring out when something is supposed or not to happen.
Most have a protocol decoder feature which helps a lot visually when you're looking at bytes.
Then some imagination helps to determine why. It's one step better than doing it on a scope.