Atmega_Hex_Uploader_Fixed_Filename: Cannot read file

[noeldum]

I am using an Arduino Mega and have the hardware well setup now.

I have first been using the sketch Atmega_Hex_Uploader. I can read the SD card. I can also flash the hex file to the target. No problem. All work really well.

Now using the same hardware I uploaded the sketch Atmega_Hex_Uploader_Fixed_Filename to the mega. However I can not get any further than the error "Can not read file" which is 2 blink of the red LED.

I checked everything. Even tried formatting my SD card. I have no idea what's going on. Even tried a different hex file.

Would you guys have any pointers what to check?

[noeldum]

Making progress. This is probably a bug.
FYI I am using the plain default parameters.

#define CROSSROADS_PROGRAMMING_BOARD false
#define NO_ENCODER true
#define HEX_FILE_NAMES true

If I add a line like this below
strcpy (name, wantedFile); // use fixed name

Just before the line

arduino_sketches/Atmega_Hex_Uploader_Fixed_Filename/Atmega_Hex_Uploader_Fixed_Filename.ino

Line 1317 in 5a5d896

if (readHexFile(name, checkFile))

I get it to work.

I suspect the problem comes from the line below which does not seem to be executed using the parameters I described above.

arduino_sketches/Atmega_Hex_Uploader_Fixed_Filename/Atmega_Hex_Uploader_Fixed_Filename.ino

Line 1441 in 5a5d896

strcpy (name, wantedFile); // use fixed name

The if/else for the compiler instructions are maybe not working well. But I can't tell what it is for now.

[noeldum]

After analysing the code a bit further I found how to make use of the sketch and work around issues.

When the sketch starts it first flashes the error code "can not read file" (2 blinks). This is clearly misleading for the user as we tend to trust the reported error. In fact I realised this is just the waiting status (probably unmanaged).

Then the button has to be pressed for a good while to make it into action. This is certainly caused by the delay(500) and other blocking functions. I did press that button in my earlier tests but only did quick press which did not action the programming call.
The blink function also using delay(1000) makes the system interaction unpredictable.

[nickgammon]

The blinking LEDs are supposed to be an error, and thus it doesn't matter if the button is unresponsive. According to https://www.gammon.com.au/forum/?id=11638&reply=5#reply5 you should see the "ready" LED on steadily, and it should respond to the button press.

[noeldum]

Hi Nick, Thank you for joining the conversation and creating this awesome work.

If you use the sketch with default parameters as currently published you will notice the error code 'can not read file' from boot time.
Looking at the code this behavior is anticipated as the line
strcpy (name, wantedFile);
is never executed (not until the button is pressed).

Then after a long press on the button things get in order somehow.

Noted for the blocking state when error codes are blinked. I finally found this to be manageable on a user side.

There is also another issue where the sketch keeps programming the target over and over indefinitely. I am not sure if this was programmed intentionally or not.

FYI I have modified the sketch for my own use. I can post the resulting code if you are interested. It is only the loop() function that has been changed. I find my sketch much more pleasant to work with. The button interaction is immediate. I also made the led lit still while the program is waiting (something blinking constantly on my desk really bugs me). Also it programs the target only once the button is pressed (not indefinitely).

[nickgammon]

It sounds to me like a problem with your initiating button. The fact that it displays a message about file not found on startup, and then keeps reprogramming the chip, is definitely not designed in. That message about the file could be because the button is considered down (due to a wiring problem) before the SD card initialises. That would account for your problems.

[noeldum]

Yes that must be it because I have my button designed with a pull down resistor.

I just notice this comment on your site which I have missed.

"A "start programming" switch on D2, normally open, which is connected to Ground when closed."

Luckily I won't have to redo my design again as there is an internal pull up from the line below. I will just need to remove the resistor and hopefully voila.

arduino_sketches/Atmega_Hex_Uploader_Fixed_Filename/Atmega_Hex_Uploader_Fixed_Filename.ino

Line 1261 in 5a5d896

digitalWrite (startSwitch, HIGH);

I'll test this during the week then.

[nickgammon]

Since my code sets the switch to INPUT_PULLUP, you are defeating that with your pulldown resistor. Thus removing the resistor should fix it. Well, looking at the line of code you quoted, it was doing the "old fashioned way" of writing a HIGH to an INPUT pin. That is the same as INPUT_PULLUP. However the input pullup is weak (around 50k ohm I think) so if you had a 10k resistor as a pulldown, the code would think the switch was always down, causing the problems you noted.

[noeldum]

Ok. Tested and I confirm this is the case.