New midipal and trying to run modified source code

Hi everyone,

I have just completed building a Midipal! Picture attached, but no case yet I’m afraid

This is my first post here; so I’ll start by saying a big thanks to @pichenettes for making his amazing work freely available for others to reproduce and learn from, and for devoting so much time to help out the community. Thank you so much!!!

So now to my question: I’ve built the Midipal from scratch and am able to program the ATMega chip using my programmer, which is a USBAsp clone. Everything works fine if I use the midipal_flash_golden.hex and midipal_eeprom.hex files from the Github repo.

But, I am interested in modifying the Midipal firmware, and so I cloned the github repo and made some changes in order for it to compile on my (current) version on GCC, as well as merging some more recent commits from the Avril/AVRlib repo. I also modified the setup routine to flash the red LED on boot (this is useful for debugging). Using the provided makefiles and avrdude, I compiled and programmed the modified firmware.

When I power on the midipal, the red LED flashes to signal the boot, and it does seem to be in monitor mode, since I can attach a MIDI keyboard and see the LEDs flash when I press the keys. However, the display does not work at all (even though it worked with the vanilla firmware files from Github). I can also play with the encoder, and trigger reboots (judging by the red LED flash on reset) sometimes, for example by holding the encoder down and seemingly trying to select another app. Or, if I’m lucky I can find a random sequence of turns and clicks that causes the Midi OUT led to flash rhythmically, like it’s one of the MIDI signal generating apps.

Running avr-size on the the compiled firmware file gives the following output. So even after adding the bootloader, I don’t think it’s too big (right?)
text data bss dec hex filename
0 29470 0 29470 731e build/midipal/midipal.hex

I noticed there seems to be no way of generating midipal_eeprom_golden.hex, from the makefiles. So even if I recompile the firmware, this file is not updated. Could this be the cause of the problem? How are the midipal_{eeprom,flash}_golden.hex files created?

Okay, I don’t think the EEPROM file is the most likely cause of the problem. (And, if I’ve understood things correctly, you can create it just by running make build/midipal/midipal.eep). It’s probably because of the changes I made in order to get the code to compile. The old prog_uintX_t types are deprecated and my GCC didn’t like it when I tried to use -D__PROG_TYPES_COMPAT__ (it actually said something like, ‘giving up due to too many errors’).

So I tried to refactor the code to use PROGMEM in the non-deprecated way. This primarily meant changes to resource_manager, and the AppInfo structs. Now, everything compiles without warnings even with -pedantic, but I wonder think that the resets might be due to a memory access error surrounding PROGMEM. If anyone is interested, I’ve put my modifications on my Github repo.

The display doesn’t work, so maybe loading strings from memory is broken, and it seems like if I exit monitor mode and then select any other app, it causes a reset. The exception is note nuke since it’s not an app, which i can reach by turning the encoder all the way to the right and then left two clicks.

Apologies - this is turning into a debugging thread. :sweat_smile:

UPDATE: I may have found the culprit in the disassembly:

avr-objdump -D build/midipal/midipal.elf
0080012f <_ZN6avrlib15BufferedDisplayINS_10Hd44780LcdINS_4GpioINS_4PortINS_12PINDRegisterENS_13PORTDRegisterENS_12DDRDRegisterEEELh2EEENS2_IS7_Lh3EEENS_12ParallelPortIS7_LNS_16ParallelPortModeE1EEELh8ELh1EEEE17cursor_character_E>:
  80012f:	Address 0x000000000080012f is out of bounds.

But this is weird, since the size test still doesn’t seem to show it’s too large

avr-objdump -P mem-usage build/midipal/midipal.elf 

Program:   29470 bytes (89.9% Full)
(.text + .data + .bootloader)
Data:       1931 bytes (94.3% Full)
(.data + .bss + .noinit)

Any thoughts would be appreciated

Given that the last changes to the MIDIpal code brought the code size a few bytes from the available flash size, you really have to stick to the same AVR GCC version as I do (4.3.3) to avoid such inconveniences.

The golden files are obtained by programming the bootloader and main .hex to the unit, letting it boot, then taking a snapshot of the flash and eeprom using avrdude. You shouldn’t bother about those, they have been prepared at the time the little things were still being mass-manufactured, the factory used AVR Studio and flashed those files. They probably correspond to a very dated version of the firmware.

Okay, I went back to the original version of the code and got it to compile with much fewer changes, by making use of -D__PROG_TYPES_COMPAT__. I then excluded some apps to reduce the code size, but it still didn’t fix the display issue.

I’ll try to get GCC 4.3.3 in case it does other things differently, but do you by any chance still have the .elf file corresponding to the midipal_flash_golden.hex (with debugging symbols)?

Also, I’m trying to debug the display by manipulating midipal::lcd and midipal::display directly, but I’m having a lot of trouble getting anything to show up on the LCD. I can’t figure out how to call lcd.Tick() and display.Tick() (from hd4470_lcd.h and buffered_display.h respectively). Are you able to explain briefly how they’re meant to be used? I have seen their use in but I feel like there are some implicit timing constraints that I’m not meeting with my test code.