Boot Reset vector

[lasithf1]

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]

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]

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]

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]

Thanks a lot! I will try it.

[livius147]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

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]

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.