updating pycubed firmware for mainboardv05

[maholli]

PyCubed users:

1. Note pin changes between mainboardv04 to mainboardv05!
2. Remember that pycubed's low-level boot counter is not present on the circuitpython main branch. This is because a truly low-level boot counter implementation requires modifications to circuitpython's main.c file.
   • To implement the PyCubed boot counter for yourself, add the following to /main.c

     #include "shared-bindings/nvm/ByteArray.h" // PYCUBED BOOT COUNTER

     Prior to the run_code_py() definition, add:

     // PYCUBED BOOT COUNTER
     nvm_bytearray_obj_t bootcnt = {
         .base = {
             .type = &nvm_bytearray_type
                 },
         .len = ( uint32_t) 8192,
         .start_address = (uint8_t*) (0x00080000 - 8192)
         };
     uint8_t value_out = 0;

     Then INSIDE the run_code_py() function definition, and before the line pyexec_result_t result;, add:

         // PYCUBED BOOT COUNTER
         common_hal_nvm_bytearray_get_bytes(&bootcnt,0,1,&value_out);
         ++value_out;
         common_hal_nvm_bytearray_set_bytes(&bootcnt,0,&value_out,1);

[tannewt]

How about making a new board def for the new revision? That way the old one will still work. You can add the boot counter behind a flag and then merge it in if you want to be on main.

[maholli]

How about making a new board def for the new revision? That way the old one will still work. You can add the boot counter behind a flag and then merge it in if you want to be on main.

@tannewt are seperate board defs your preferred method of handling major board revisions? Part of me yearns for a cleaner solution than that, especially since folks are wanting firmware for multiple D51 flash sizes (J19 and J20, for example). Maybe solution is discrete board defs but easily managed via revisions or configuration drop down on the board's circuitpython.org/downloads page?

Excited about having the boot counter feature on main. Will do! Thanks!

[tannewt]

Ya, separate board defs are preferred. Board revisions in my book don't change pinouts. Revisions would only change layout or compatible parts.

We have lots of infrastructure to handle many boards. (I just added a tweak to CI to only build changed boards for PRs.) Adding another level like revision or configuration will just add complexity to the tooling.

[maholli]

@tannewt if it's alright with you, I've elected not to create separate board defs for the PyCubed update since it would require 6 new defs in the boards directory: pycubed-v04_J19, pycubed-v04_J20, pycubed-v05_J19, pycubed-v05_J20.

I did, however, add the boot counter in main.c via maholli@fa83c1c. When you have a moment, can you review the implementation? Usage details below.

Boot Counter Usage

The boot counter is a uint8_t single-byte counter stored in the first NVM byte position (micrcontroller.nvm[0]). The counter increments by 1 each time the board boots, regardless if it's a hard or soft reset.

Enable the boot counter by adding #define CIRCUITPY_BOOT_COUNTER 1 to your board's mpconfigboard.h file. Note that an error will be thrown during the build if CIRCUITPY_INTERNAL_NVM_SIZE is not also set within mpconfigboard.h.

[tannewt]

I really don't like you changing the original board. It's a bad policy because the old boards can never be updated then. Just add two new boards v5 and v5 mram.

[maholli]

I think this fixes nvm object concerns, would be nice to have a sanity check of the implications, though.

[dhalbert]

@maholli are the boards distributed, or are these only in your lab? I can see you not wanting a Cartesian product of new boards for every revision.

[maholli]

@maholli are the boards distributed, or are these only in your lab? I can see you not wanting a Cartesian product of new boards for every revision.

Good question. Yes, students have built hundreds of these boards around the world, but I also expect the same to occur for the new revision. Part of me feels folks can just dig up the appropriate commit if they want to build CP for a prior revision (with minor fiddling), but I also appreciate Scott's reasoning. I'll stick to new board defs for now.

[maholli]

Ok @tannewt, with dbd557d this PR has changed the following:

1. Split existing board defs pycubed and pycubed_mram into:
   a. pycubed_v04 and pycubed_mram_v04
   b. pycubed_v05 and pycubed_mram_v05
   An update to circuitpython-org repo will be merged once this PR is accepted.
2. Added boot counter to main.c using existing common_hal_mcu_nvm_obj object.

Ready for checking and approval.

[tannewt]

Please don't change the id (aka folder name) of the existing boards. We've done it in rare cases when something hasn't been released yet. In this case, since it is released, you'll create a discontinuity with all folks currently using it. You can add a comment to one of the files that it is V4 of the board. (One discontinuity would not being able to see all of the older releases like you can here: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/pycubed/en_US/)

[maholli]

Please don't change the id (aka folder name) of the existing boards. We've done it in rare cases when something hasn't been released yet. In this case, since it is released, you'll create a discontinuity with all folks currently using it. You can add a comment to one of the files that it is V4 of the board. (One discontinuity would not being able to see all of the older releases like you can here: https://adafruit-circuit-python.s3.amazonaws.com/index.html?prefix=bin/pycubed/en_US/)

Completely understood. I restored the pycubed board defs. @tannewt Do you prefer the redundant (but labeled) pycubed_v04 board def be removed?

[tannewt]

Completely understood. I restored the pycubed board defs. @tannewt Do you prefer the redundant (but labeled) pycubed_v04 board def be removed?

Yes, please remove the new v4 def and leave the existing one.

[maholli]

Completely understood. I restored the pycubed board defs. @tannewt Do you prefer the redundant (but labeled) pycubed_v04 board def be removed?

Yes, please remove the new v4 def and leave the existing one.

Done. 👍

[dhalbert]

Each commit causes a set of builds, so I am cancelling the older ones just to save build time.

[tannewt]

Two more minor things. Thanks!

[tannewt]

Looks good. Thanks for sticking with it!