Moon Day

Plan for today:

• Test new FEDM heartbeat function.
• When Darryl gets here, have him start work on replicating the datapath.

Had a thought about why the software doesn't start running automatically after board programming:  Currently, .rwdata is allocated to the working_memory module, which can't be initialized because it is in M-RAM.  Yet, .rwdata may contain global variables that need to be initialized.  We could try moving it to the extra_RAM module (in M512 blocks) and see if that fixes the problem.  However, depending on how big the .rwdata section is, we might not have room for it...

Alternatively (looking through docs), it looks like turning on the enable_alt_load_copy_rwdata flag in the BSP might help.  (This might also solve the current problem that processor reset doesn't work properly.)  I'll try that first, and if that doesn't help, I'll try moving .rwdata to extra_RAM.

Currently waiting for Quartus to finish a recompile, with the new timer_0 peripheral added to the SOPC design, and the enable_alt_load_copy_rwdata flag turned on in the new BSP (which I already compiled).  At some point, I need to take a look at incremental compilation to speed up Quartus!

OK, enable_alt_load_copy_rwdata broke everything; not sure why.  Turned it back off and things worked at first, but then the FW crashed after producing two heartbeats!  Weird.

Moved .rwdata to extra_RAM temporarily and rebuilding, so I can assess whether we have enough M512's left to get away with that.  Nope, I'm 544 bytes short.  But, that's not too bad!  According to the fitter report, we have 17 M512s left, which is 32x18x17= 9,792 bits = 1,224 bytes > 1 kB.  So we could increase the extra_RAM size by 1K (from 8K to 9K), which should free up enough room for the .rwdata (for now).

Regenerated SOPC system, opened BSP editor, went to Linker Script tab and hit "Restore Defaults..." in the top pane.  extra_RAM size now shows as 9216 bytes as expected.  Regenerating target files.  Rebuilding project.

Argh, now it's complaining it needs another 900 bytes for the .bss section.  Wonder if I should just move .bss back to working_memory.  I think I saw code that initializes it to 0 on startup anyway.  Let's try that...  Editing BSP, regenerating files, rebuilding...

Now having a GP offset problem, presumably resulting from moving .rwdata into extra_RAM.  Apparently GP points into the .rwdata section, but also needs to point to the start of working_memory (perhaps to initialize .bss), which is now too far away.  Relocating the 9K extra_RAM to 0x1c000-1e3ff, and the 64K working_memory to 0x20000-0x2ffff, so that the GP (which points to somewhere in extra_RAM) doesn't have as reach out as far to reference the start of working_memory, and the offset will fit in 16 bits.

Saving SOPC system, starting BSP editor, restoring defaults, saving BSP, regenerating BSP makefiles, rebuilding project.  It links!

Sweet; by moving .rwdata to extra_RAM we actually increased the available stack+heap space to 62K.  Changed the code to use 62-15 = 47KB for the pulse buffer.

Rebuilding Quartus so that (with luck) the system will actually run automatically on startup again now.  It does!  I should perhaps retry enable_alt_load_copy_rwdata, but maybe it's only supposed to be on when the design is loaded from the EEPROM?

Still having a crash after 2nd heartbeat.  Maybe I have to stop the alarm within the callback in order to reuse the same alarm data structure?  No, that made things worse.  Finally solved the problem by alternating between two different alarm data structures.

Things are running pretty smoothly now.  Trying to recompile the present firmware into Quartus so that I can try running it from EEPROM.  That works!  Next up:  Try to get the CPU_RESET command working.  (Don't waste *too* much time on it, though...)