Boot Reset vector #25

lasithf1 · 2017-12-12T12:30:18Z

Hello Falks,

I was trying to use this with my ATMega1284P, however first run going smoothly which loads the bin file in my SD card, for some reason subsequent resets does not kick start the bootloader and therefore does not load any more bin files from the SD card.

Is this something to do with the Boot Reset Vector?

Any idea how can I continue to use the bootloader so that any time a FIRMWARE.BIN on SD card will get loaded upon reset (and from the program I can delete the BIN file)

To note, I was using the boards manager installation on Arduino 1.8.1

Cheers,
Las

lasithf · 2018-01-21T22:34:43Z

Guys, Just to give you an update,

I was able to compile the codebase with UART debug messages and can confirmed that the bootloader is calling every time at the system reboot. So there's no issues with the Boot Reset Vector or anything, bootloader kicks in very well.

As indicated earlier, initial firmware loading from the SD card has no issues and neither SD card read/write using arduino SD example has any issues, all working good - this will eliminate any concerns about the SD card wiring to the system ATMega1284p.

However at subsequent reboots causing disk_initialize() to return STA_NOINIT which resulting firmware download process to stop working.

I have no idea why this STA_NOINIT returns.

Any thoughts?

livius147 · 2018-03-13T20:33:46Z

Hi all,
I have the same problem: only at first boot the bootloader flashes the FIRMWARE.BIN.
Have you any news about this topic?

Regards!

lasithf1 · 2018-03-13T21:40:49Z

Mine was due to a 'bad' SD card although the first time working. I've debug the bootloader code and found it's failing to initialize at the second run. I changed the SD card and all working smoothly. I suggest you to try the same if you haven't yet.

…

On Wed, Mar 14, 2018, 7:33 AM livius147 ***@***.***> wrote: Hi all, I have the same problem: only at first boot the bootloader flashes the FIRMWARE.BIN. Have you any news about this topic? Regards! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Ag4Y24m6R-olviqpEHzRFsOY3gFiG-Y2ks5teC0rgaJpZM4Q-5Nh> .

livius147 · 2018-03-13T21:43:12Z

Thanks a lot! I will try it.

livius147 · 2018-03-14T17:17:15Z

I found a workaround; I modified the main.c as follows:

diff --git a/Arduino/avr_boot/main.c b/Arduino/avr_boot/main.c
index 8beeb86..23c3761 100644
--- a/Arduino/avr_boot/main.c
+++ b/Arduino/avr_boot/main.c
@@ -148,7 +148,10 @@ void doFlash() {
 void checkFile() {
         uint8_t fresult;
 
-       fresult = pf_mount(&Fatfs);     /* Initialize file system */
+       while((fresult = pf_mount(&Fatfs))!=FR_OK) {
+               _delay_ms(100);
+       }
+               /* Initialize file system */
 
        if (fresult != FR_OK) { /* File System could not be mounted */
          #if USE_UART

With this patch the bootloader reads and writes the FIRMWARE.BIN file at every startup.
I think that there is a problem with timing (I am using ATMEGE328P, 8MHz internal, CS pin 10): maybe the _delay_ms() function does not work properly.
Please give me your feedback.

P.S.: this workaround must be modified to avoid infinite loop.

livius147 · 2018-03-14T22:25:12Z

I suggest something like this:

diff --git a/Arduino/avr_boot/main.c b/Arduino/avr_boot/main.c
index 8beeb86..fdedd79 100644
--- a/Arduino/avr_boot/main.c
+++ b/Arduino/avr_boot/main.c
@@ -147,8 +147,14 @@ void doFlash() {
 
 void checkFile() {
         uint8_t fresult;
+       uint8_t cnt = 0;
 
-       fresult = pf_mount(&Fatfs);     /* Initialize file system */
+               /* Initialize file system */
+       while ((fresult = pf_mount(&Fatfs)) != FR_OK && cnt<10) 
+       {
+               _delay_ms(100);
+               cnt++;
+       }
 
        if (fresult != FR_OK) { /* File System could not be mounted */
          #if USE_UART

lasithf · 2018-03-15T11:29:42Z

did you test this?

…

On Thu, Mar 15, 2018 at 9:25 AM, livius147 ***@***.***> wrote: I suggest something like this: `diff --git a/Arduino/avr_boot/main.c b/Arduino/avr_boot/main.c index 8beeb86..fdedd79 100644 --- a/Arduino/avr_boot/main.c +++ b/Arduino/avr_boot/main.c @@ -147,8 +147,14 @@ void doFlash() { void checkFile() { uint8_t fresult; - uint8_t cnt = 0; - fresult = pf_mount(&Fatfs); /* Initialize file system */ - /* Initialize file system */ - while ((fresult = pf_mount(&Fatfs)) != FR_OK && cnt<10) - { - _delay_ms(100); - cnt++; - } if (fresult != FR_OK) { /* File System could not be mounted */ #if USE_UART ` — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AMPrDYCzA_wWfKryCPraU6LYPrdQGnloks5teZjJgaJpZM4Q-5Nh> .

livius147 · 2018-03-15T13:23:49Z

Yes, I tested it and it works. The maximum "wait time" in that loop is 100ms x 10, that is 1s.
It would be nice to understand the real reason of this unplanned behavior.
Regards.

livius147 · 2018-03-16T06:45:34Z

@zevero may you consider to add this patch to the official code? This patch retries mounting the sdcard fat filesystem: with my configuration (above described), pf_mount is unable to mount the sdcard at first call. So I added 10 retries with 100ms sleep.

lasithf · 2019-04-17T00:27:15Z

Mine was due to a 'bad' SD card although the first time working. I've debug the bootloader code and found it's failing to initialize at the second run. I changed the SD card and all working smoothly. I suggest you to try the same if you haven't yet.
…
On Wed, Mar 14, 2018, 7:33 AM livius147 @.***> wrote: Hi all, I have the same problem: only at first boot the bootloader flashes the FIRMWARE.BIN. Have you any news about this topic? Regards! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/Ag4Y24m6R-olviqpEHzRFsOY3gFiG-Y2ks5teC0rgaJpZM4Q-5Nh .

Though I said this was due to a 'bad' SD card, I've started to experience this again and this time I've checked with 4 different microSD cards and they all come up with the same issue, this time not even the first time bootloading works, it just stay there with AVR_BOOT and stuck in the disk_initialize() always returns STA_NOINIT and retry.

I even tried with 100 ms delay loop with a count of 10, no luck!

Any idea what could go wrong here?

In a separate test, with these 4 microSD cards with the same hardware (custom board with commercial grade PCB/SMDs) for basic read/write and they all works fine. So I can assume the hardware is working fine.

Then it seems the problem is with the FatFs disk_initialize(), I don't know what causing this issue returning always STA_NOINIT.

All of these microSD cards were 1GB and formatted before use.

Highly appreciate your feedback.

lasithf · 2019-04-17T11:52:38Z

I'm just wondering whether SPI speed could be the issue here? I can see my SD read/write functions successfully using Arduino SdFat library with 50MHz. What speed this AVR_BOOT SPI is working?

I wonder lowering the speed may be helpful?

@zevero could you please help?

lasithf · 2019-05-09T11:19:25Z

Anyone else experienced this issue before? I really appreciate if someone could shed some light here.

the main problem is with the FatFs disk_initialize(), I don't know what causing this issue returning always STA_NOINIT.

@zevero , @per1234 could you please help?

livius147 · 2019-05-12T11:14:30Z

Did you test accessing the sdcard, with the same wiring scheme, with a test code? Did you check if the circuit has a voltage drop? If the voltage is not stable the burnout circuit of atmega shuts down the microcontroller. The burnout thresholds can be changed. I suggest you to put a large capacitor in the main power line (200-500uF) and test again with the patch I suggested. I am using it without problem.

lasithf · 2019-05-12T15:09:53Z

Just another thought, do I need to use any pull up resistors for any of the SS, CLK, MISO or MOSI pins?

Also how do I change the SPI speed? I checked currently bootloader SPI is running at 8 MHz between micro and SD card, can I lower the speed?

P.S. there's no brownout indication as I am printing the reset cause as well, also I checked the wiring seems okay.

livius147 · 2019-05-12T20:14:13Z

No pull up resistors are needed for SPI, only for i2c.
I haven't modified the SPI speed.
From where do you take the 3.3 voltage for powering up the sdcard? Is the sdcard ground connected to the uController ground? Try reducing the wiring from the uC to the sdcard.

lasithf · 2019-05-12T20:58:07Z

May I know what is your board? A custom made one or a standard shield?

Voltage shouldn't be a problem as exactly the same setup perfectly works with sdFat/SD library in another arduino test code.

My board is a custom made PCB with copper tracks between micro and SD card which goes through a TXB0104 to the SD adapter.

When I use my vero board version with wires to a SD card module (something like this.. https://www.ebay.com.au/i/382813690302?chn=ps), bootloader works pretty well.

Would you be able to share your bootloader HEX file, just to give another try. Below are my configuration:
ATMega1284P, 16MHz,
SS - PB4, MOSI - PB5, MISO - PB6, SCK - PB7.

livius147 · 2019-05-13T05:11:20Z

This is my schematic: the Vcc for the sdcard adapter comes from a mosfet which is able to switch on and of fthe sdcard.

Here you can find the connection between ATMEGA328P-PU and the sdcard slot: the 3.3v has some capacitors to increase the stability, the whole circuit is powerd up by 3.3v. No translators have been used. I modified the bootloader to manage the mosfet device via an enable pin (PD2, named EN_33).
I found some troubles with brownout during my development: I found the problem using an oscilloscope probe on the main voltage line. When you use the sd/fat standard library, you are in a steady state and not in a boot process.

lasithf · 2019-05-13T05:23:54Z

Thanks for sharing, I can confirm mine also have a smoothing cap near SD card, but my system runs on 5V and therefore I use level translators.

Just a question, how do you compile the bootloader? I am using WINAVR in Windows environment, hope that shouldn't be an issue.

Also did you ever try to use SDHC cards? (Say FAT32 8/16/32GB versions) with this bootloader?

livius147 · 2019-05-13T05:49:43Z

If I am not wrong, I am using a 8G sdcard formatted in fat16; but I am not sure of this config. I will check this afternoon. In order to enable/disable fat16/32 you have to change the configuration in the pff/src directory.

lasithf · 2019-05-13T06:05:51Z

Thanks,

how do you compile the bootloader? I am using WINAVR in Windows environment, hope that shouldn't be an issue.

livius147 · 2019-05-13T06:38:06Z

I develop all my codes under linux.

lasithf · 2019-05-13T06:47:32Z

Okay thanks, do you ever test the SPI speed between micro and SD card? I am seeing an 8 MHz clock frequency.

livius147 · 2019-05-13T17:32:21Z

I put a digital probe on the pin PB5/CLK and I read ~530kHz during boot and 250kHz when the arduino library reads the sdcard. My atmega328 runs with an internal clock @ 8MHz.

lasithf · 2019-05-14T01:18:40Z

That's strange, wondering why I am seeing a 8MHz CLK on the SPI between micro and SD card, I'm using 16MHz external low power.
Could this be an issue of I am using the Arduino board manager to load the AVR_BOOT bootloader in Windows environment?

I wonder whether there's any difference between building in Windows (using WINAVR) vs building in Linux of AVR_BOOT project. I am going to build the project now in a Linux box, will see how it goes.

lasithf · 2019-05-19T12:21:59Z

I've compile the bootloader in Ubuntu environment, glad this worked. I've tested with a small code (~1K Bin) with test LED blink and I can reload it over and over again using the bootloader. The bootload process seems taking less than 5 seconds.

However if I compile a code with 11K Bin file, this just does not work, I can see bootloader is keep writing to the flash as it's SS LED is blinks, but I've waited for more than 2 min, nothing happened.

Any idea what would be the issue?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Boot Reset vector #25

Boot Reset vector #25

lasithf1 commented Dec 12, 2017

lasithf commented Jan 21, 2018

livius147 commented Mar 13, 2018

lasithf1 commented Mar 13, 2018 via email

livius147 commented Mar 13, 2018

livius147 commented Mar 14, 2018 •

edited

Loading

livius147 commented Mar 14, 2018 •

edited

Loading

lasithf commented Mar 15, 2018 via email

livius147 commented Mar 15, 2018

livius147 commented Mar 16, 2018

lasithf commented Apr 17, 2019

lasithf commented Apr 17, 2019

lasithf commented May 9, 2019

livius147 commented May 12, 2019

lasithf commented May 12, 2019 •

edited

Loading

livius147 commented May 12, 2019

lasithf commented May 12, 2019 •

edited

Loading

livius147 commented May 13, 2019

lasithf commented May 13, 2019

livius147 commented May 13, 2019

lasithf commented May 13, 2019

livius147 commented May 13, 2019

lasithf commented May 13, 2019

livius147 commented May 13, 2019 •

edited

Loading

lasithf commented May 14, 2019

lasithf commented May 19, 2019

Boot Reset vector #25

Boot Reset vector #25

Comments

lasithf1 commented Dec 12, 2017

lasithf commented Jan 21, 2018

livius147 commented Mar 13, 2018

lasithf1 commented Mar 13, 2018 via email

livius147 commented Mar 13, 2018

livius147 commented Mar 14, 2018 • edited Loading

livius147 commented Mar 14, 2018 • edited Loading

lasithf commented Mar 15, 2018 via email

livius147 commented Mar 15, 2018

livius147 commented Mar 16, 2018

lasithf commented Apr 17, 2019

lasithf commented Apr 17, 2019

lasithf commented May 9, 2019

livius147 commented May 12, 2019

lasithf commented May 12, 2019 • edited Loading

livius147 commented May 12, 2019

lasithf commented May 12, 2019 • edited Loading

livius147 commented May 13, 2019

lasithf commented May 13, 2019

livius147 commented May 13, 2019

lasithf commented May 13, 2019

livius147 commented May 13, 2019

lasithf commented May 13, 2019

livius147 commented May 13, 2019 • edited Loading

lasithf commented May 14, 2019

lasithf commented May 19, 2019

livius147 commented Mar 14, 2018 •

edited

Loading

livius147 commented Mar 14, 2018 •

edited

Loading

lasithf commented May 12, 2019 •

edited

Loading

lasithf commented May 12, 2019 •

edited

Loading

livius147 commented May 13, 2019 •

edited

Loading