Update fprime-baremetal-reference to support building with fprime v3.4.0

[capsulecorplab]

Encountered the following CMake Error while attempting to run fprime-util generate with fprime v3.4.0

[ethancheez]

I also encountered this error when upgrading to v3.4.0.

Solution: I had to create a new virtual ennvironment and reinstall fprime-tools. Simply running pip install -U fprime-tools in an existing venv did not actually seem to upgrade FPP to v2.0.1.

As a side note, fprime v3.4.0 modified Svc.Time. It is now an interface. So you would have to change that in the instances.fpp (I think). I plan to modify the Arduino cookie cutter to fix this.

[ethancheez]

See here for updated deployments using fprime v3.4.0.

You would also need to update fprime-arduino. Currently the changes are in my personal repo here

[capsulecorplab]

Sorry, I should have check which version of my environment I was running. Just did a new build (and pre-release) of my environment here, but now I'm getting the following build error

Also, which instances.fpp should I change?

./RadioPassthrough/Top/instances.fpp
./fprime/Ref/Top/instances.fpp
./fprime/RPI/Top/instances.fpp
./BaremetalReference/Top/instances.fpp
./BaseDeployment/Top/instances.fpp

[ethancheez]

I believe the change using "Generic" was a very recent commit to fprime, that's not part of the v3.4.0 release.

So if your current fprime version is release v3.4.0, and not the most updated commit of devel branch, that might be why.

Do you think I should change fprime-arduino to follow the release of fprime v3.4.0 or the most latest commit of devel?

And you would change the instances.fpp of the BaremetalReference, BaseDeployment, and RadioPassthrough deployments.

[ethancheez]

I believe it is this commit that adds "Generic" and FPRIME_PLATFORM

[capsulecorplab]

I typically prefer to point submodules to semver tagged commits. Otherwise it gets ugly and I have to point to arbitrary commits in CI like here https://github.com/capsulecorplab/fprime-workspace-image/blob/main/playbook.yaml#L327

[ethancheez]

I typically prefer to point submodules to semver tagged commits. Otherwise it gets ugly and I have to point to arbitrary commits in CI like here https://github.com/capsulecorplab/fprime-workspace-image/blob/main/playbook.yaml#L327

Okay, I can revert that commit in fprime-arduino so that you won't run into that error. Then I'll add when the next fprime version is released. I'll let you know when I get that done. For now, you can manually edit the rpipicow.cmake file, or whichever board you are building for:

Change Generic to ArduinoFw

[capsulecorplab]

Just checked out https://github.com/nasa/fprime/commit/0ed8e0b74e2cc99e519576f6cfc250e7d21ca10c and was able to build for the teensy41! Encountered an error while attempting to build for the rpipicow though

[capsulecorplab]

Sorry, wrong screenshot. I meant to upload this one for the rpipicow; this was after changing Generic to ArduinoFw

[capsulecorplab]

Similar error for the featherM0

[ethancheez]

If you checked out the latest commit, you don't need to change Generic to ArduinoFw.

Also I realized there is another file to change if you are using the v3.4.0 release rather than the latest commit: fprime-arduino.cmake, line 1. Change Generic to ArduinoFw. Essentially everything from this commit would be reverted.

[ethancheez]

If you pull my fprime-arduino fprime3.4.0 branch, everything should work for the release commit of fprime now. Although I don't think building the BaremetalReference and RadioPassthrough deployments will work for the rpipicow since the RadioHead library I used was specific for the Teensy boards.

I've been using fprime-tutorial-arduino-blinker as a test for featherM0, rpipicow, teensy32/40/41, and thingplusrp2040 because there's no hardware-specific components, and they seem to all build.

[capsulecorplab]

Checking out fprime3.4.0 on fprime-arduino seems to have broken the teensy41 build for me

[ethancheez]

Does your deployment CMakeLists.txt file look like this?

The important line that must be called is:

finalize_arduino_executable("${FPRIME_CURRENT_MODULE}")

The error you're getting usually occuers when the arduino executables are not being linked properly, hence the undefined reference to SPI, Wire, etc.

[capsulecorplab]

Ah, forgot to do a pull on fprime3.4.0 in the project root itself. teensy41 and featherM0 seem to be building fine! Though still encountering errors with rpipicow

teensy41

featherm0

rpipicow

[ethancheez]

Yeah I also got those errors for the rpipicow. What I noticed:

1. For some reason the rp2040 package that is installed from the arduino-cli has weird character quotes around 1'000'000. That honestly looks like a bug on the rp2040 package... not sure. It appears in their source code too. But I manually removed those single quotes from the file so that it is just 1000000, and that fixes that error.
2. The RadioHead library is specific to the Teensy boards. The SPI implementation for the rpipicow and Teensy packages seem to be different (hence the error on that bitOrder). I haven't gotten around to fixing this so for now, the deployment is only compatible for the Teensy :(

[ethancheez]

I added support for rpipicow. Try pull on the fprime3.4.0 branch and build again. It built for me, never tested on hardware though.

You also need to install:

arduino-cli lib install RadioHead

[capsulecorplab]

Triggered a build of my environment to install RadioHead - will report back once it's pulled and running!

In the meantime, going to prepare what physical boards I can test... Is there a wiring diagram I should refer to for testing any combination of boards that need to connect to a radio transceiver? I currently have two Adafruit Feather RP2040's, two Adafruit RFM69HCW Transceiver Radio Breakout board's, a Teensy 4.1, and two Pico W's

[ethancheez]

I don't have wiring diagrams, but the connections should be similar.

The SPI wiring should be SPI0 (if there are multiple SPI ports on the board), or just SPI (if there is only one SPI port). The chip select (CS), interrupt (DIO0), and reset (RST) pins are set in the RFM69.hpp file here:

static const NATIVE_INT_TYPE RFM69_CS   = 8;
static const NATIVE_INT_TYPE RFM69_INT  = 3;
static const NATIVE_INT_TYPE RFM69_RST  = 4;

Note, you may have to change these if they interfere with other pins. They can be set to any GPIO pin.

Summary of wiring ports:	RFM69HCW	Adafruit FeatherM0	Adafruit Feather RP2040	Teensy 4.1	Teensy 4.0	RPi Pico W
MISO	22	GPIO20	12	12	GP16
MOSI	23	GPIO19	11	11	GP19
SCK	24	GPIO18	13	13	GP18
CS	8	GPIO25	8	8	GP17
RST	4	GPIO24	4	4	GP4
G0	3	GPIO29	3	3	GP3

The Feather RP2040 and RPi Pico W boards were untested. I got those pinouts based on the board schematic. It would be great if you are able to test them! :)

[capsulecorplab]

Yeah I also got those errors for the rpipicow. What I noticed:

1. For some reason the rp2040 package that is installed from the `arduino-cli` has weird character quotes around `1'000'000`. That honestly looks like a bug on the rp2040 package... not sure. It appears in their [source code](https://github.com/earlephilhower/arduino-pico/blob/master/cores/rp2040/RP2040Support.h#L189) too. But I manually removed those single quotes from the file so that it is just `1000000`, and that fixes that error.

2. The RadioHead library is specific to the Teensy boards. The SPI implementation for the rpipicow and Teensy packages seem to be different (hence the error on that `bitOrder`).  I haven't gotten around to fixing this so for now, the deployment is only compatible for the Teensy :(

I'm a little stuck as to how I should go about adding this fix. Currently, I just use the arduino-cli to download the board package (json file) here then install it here. Is there perhaps a fork of the arduino-pico repo that has a fixed board package I could just swap in?

[ethancheez]

Are you able to manually open /home/kasm-default-profile/.arduino15/packages/rp2040/hardware/rp2040/3.3.0/cores/rp2040/RP2040Support.h from your environment and edit it manually? I do not know of any other json file that fixes this.

Perhaps I will submit an issue to earlephilhower and see if that syntax was intended.

Edit: I found this. Digit separators were added for readability, but that would mean using C++17 standard

[capsulecorplab]

I tried manually removing the single quote digit separators in /home/kasm-default-profile/.arduino15/packages/rp2040/hardware/rp2040/3.3.0/cores/rp2040/RP2040Support.h, but I'm still getting the same token error for the rpipicow as well as the featherrp2040rfm

[ethancheez]

I think I found a fix and I'm going to push it my fprime-arduino branch in a sec. Just validating this fix didn't break anything else. Will let you know when I push it.

[ethancheez]

Okay, try pull my fprime-arduino fprime3.4.0 branch and try again

[capsulecorplab]

Yup, looks like that fixed the rp2040 builds!

[capsulecorplab]

As far as testing with hardware, I'll need two boards (one to connect to my laptop and the other to talk to) and two radio transceivers (one for each board), correct? What should I be uploading/flashing to the board connected to my laptop?

[ethancheez]

As far as testing with hardware, I'll need two boards (one to connect to my laptop and the other to talk to) and two radio transceivers (one for each board), correct? What should I be uploading/flashing to the board connected to my laptop?

Correct you need two boards with their own radios. The RadioPassthrough deployment will be on the board connected to your laptop, and the BaremetalReference deployment will be on the other one (you would still need to power it somehow, via USB or 5V power supply).

Then you would run fprime-gds on the port that is running your RadioPassthrough deployment, but using the BaremetalReference dictionary xml.

See example:

fprime-gds -n --dictionary ./build-artifacts/teensy41/BaremetalReference/dict/BaremetalReferenceTopologyAppDictionary.xml --comm-adapter uart --uart-device /dev/ttyACM0 --uart-baud 115200

To upload to your board(s), you can reference this

[capsulecorplab]

Uploaded the UF2 files for RadioPassthrough and BaremetalReference to Pico W's, wired them each to a RFM69HCW radio transceiver, ran the above fprime-gds command (but for the rpipicow), and attempted to turn on/off the LED, but the LED appears to remained unchanged.

[ethancheez]

Hmm it appears the GDS did not connect. I see a red X on the top right

[ethancheez]

Are the LEDs for both Rpi Picos blinking by default?

[capsulecorplab]

Are the LEDs for both Rpi Picos blinking by default?

Yup, they both blink when plugged into USB

[ethancheez]

Hmm it appears the GDS did not connect. I see a red X on the top right

Actually, the red X indicates that the RadioPassthrough deployment is not receiving any packets from the radio. Are you able to verify (by opening up a serial monitor on the serial port), that anything is being received?

You would need to get out of the GDS to monitor the serial port.

You should see a bunch of garbage characters, probably a bunch of boxes (☐) and random letters/numbers.

[capsulecorplab]

Would I need something like minicom installed?

[ethancheez]

Would I need something like minicom installed?

Yeah, minicom works. Or if you have an Arduino IDE, that will also work since it has a built-in serial monitor.

[ethancheez]

Likewise you can also view the serial monitor of the BaremetalReference deployment and see if it is sending anything out the radio.

You should see something like:

(rfm69) Payload Size Sent: 64

If something like this is not showing, then that means the radio isn't transmitting.

[ethancheez]

Just making sure, the pin numbers on the rpipicow is weird.

If you look at the pinout diagram, make sure in RFM69.hpp the pin numbers follow the green GPxx numbers in the diagram and not the gray-colored ones.

[capsulecorplab]

Yup, followed the green GPxx numbers in the pinout diagram. Working on installing minicom, stand by...

[ethancheez]

I tested BaremetalReference just now (on a Teensy 4.1) and the serial monitor shows this:

EVENT: (65538) (0:16,16240248) DIAGNOSTIC: LedState : LED is OFF (0)
EVENT: (65538) (0:16,16340248) DIAGNOSTIC: LedState : LED is ON (1)
EVENT: (65538) (0:16,16440248) DIAGNOSTIC: LedState : LED is OFF (0)
EVENT: (65538) (0:16,16540248) DIAGNOSTIC: LedState : LED is ON (1)
EVENT: (65792) (0:16,16550051) DIAGNOSTIC: PayloadMessageTX : Payload Size Sent: 10
EVENT: (65792) (0:16,16559629) DIAGNOSTIC: PayloadMessageTX : Payload Size Sent: 7
EVENT: (65792) (0:16,16562559) DIAGNOSTIC: PayloadMessageTX : Payload Size Sent: 52

Unfortunately I only have one radio on me currently, so I can't have both the BaremetalReference and RadioPassthrough talking to each other. But your RPi serial monitor should output the same thing.

I have a Rpi Pico W at home, but I won't be home for a while to test.

[capsulecorplab]

Got minicom up and running (with minicom -D /dev/ttyACM0), but no chatter displaying on the serial monitor for either BaremetalReference or RadioPassthrough :slightly_frowning_face:

[capsulecorplab]

I can also try testing with Teensy's (I have one Teensy 4.1 and one Teensy 3.2)

[capsulecorplab]

I just remembered, the RP2040 only provides a Mass Storage Device interface, which would explain why it's not showing up via serial monitor https://learn.adafruit.com/dude-where-s-my-com-port?view=all#rp2040-rom-bootloader-specific-3136942

[ethancheez]

I just remembered, the RP2040 only provides a Mass Storage Device interface, which would explain why it's not showing up via serial monitor https://learn.adafruit.com/dude-where-s-my-com-port?view=all#rp2040-rom-bootloader-specific-3136942

Oh yeah I remember you mentioning this a while back...

what if you have a Teensy as the RadioPassthrough and a RPi Pico W as the BaremetalReference? Then see if you are receiving anything.

[capsulecorplab]

I'm having issues with the Teensy (both the 4.1 or 3.2). My Teensy 4.1 won't show up as a serial port and my 3.2 doesn't seem to turn on its LED at all :confused:

[ethancheez]

I'm having issues with the Teensy (both the 4.1 or 3.2). My Teensy 4.1 won't show up as a serial port and my 3.2 doesn't seem to turn on its LED at all :confused:

Hmm.. I'm not sure about the 4.1, but for the 3.2 are you able to open a serial monitor to see if an ASSERT happened? There is a possibility the 3.2 doesn't have enough memory to run the BaremetalReference since it has 256KB I think?

[capsulecorplab]

I'm having issues with the Teensy (both the 4.1 or 3.2). My Teensy 4.1 won't show up as a serial port and my 3.2 doesn't seem to turn on its LED at all 😕

Hmm.. I'm not sure about the 4.1, but for the 3.2 are you able to open a serial monitor to see if an ASSERT happened? There is a possibility the 3.2 doesn't have enough memory to run the BaremetalReference since it has 256KB I think?

Nope, the serial monitor's just blank :confused:

[ethancheez]

Can you clone fprime-baremetal outside of the project, checkout to size-utility, and try the sizing utility on the teensy32 build? I want to see the memory usage of the binary.

cd fprime-baremetal
git checkout size-utility
pip install --upgrade .
baremetal-size teensy32

Edit: sorry you can actually just checkout size-utility inside of lib/fprime-baremetal instead

[capsulecorplab]

Getting a Traceback error. Not sure if that's expected

[ethancheez]

Getting a Traceback error. Not sure if that's expected

Apologies, that's a bug. Fixed it. If you pull on fprime-baremetal-reference, the submodule should be updated.

I will have to debug more as to why the teensy32 is crashing though... Unfortunately I only have Teensy 4.1, 4.0, and RPi Pico W.

[ethancheez]

For teensy41, teensy40, and teensy32, the SPI SCK pin is 13, which is the same as LED_BUILTIN. So we are configuring LED_BUILTIN for LedBlinker, which interferes with the SCK pin and therefore the teensy appears to crash.

Teensy 3.2

For your teensy 3.2, you might be able to change the mapped SCK pin. See pinout below:

It appears pin 14 can also be used as the clock. So in RFM69.cpp, you would have to add the following line before calling rfm69.init():

SPI.setSCK(14);

Example:

    if(radio_state == Fw::On::OFF)
    {
      if(this->isConnected_gpioReset_OutputPort(0))
      {
        this->gpioReset_out(0, Fw::Logic::HIGH);
        delay(10);
        this->gpioReset_out(0, Fw::Logic::LOW);
        delay(10);
      }

      SPI.setSCK(14);

      if(!rfm69.init())
      {
        Fw::Logger::logMsg("Failed to Initialize Radio\n");
        return;
      }

      rfm69.setFrequency(RFM69_FREQ);
      rfm69.setTxPower(14, true);

      Fw::Success radioSuccess = Fw::Success::SUCCESS;
      if (this->isConnected_comStatus_OutputPort(0)) {
          this->comStatus_out(0, radioSuccess);
      }

      radio_state = Fw::On::ON;
    }

Teensy 4.1

For a Teensy 4.1, unfortunately you would have to use a different SPI port. i.e. SPI1. Or, disable LedBlinker and the gpioDriver for LED_BUILTIN pin.

Teensy 4.0

There is only one SPI port broken out to the pins, SPI1 is sadly broken out into pads on the underside of the board. So you would have to disable LedBlinker and the gpioDriver for LED_BUILTIN...

[ethancheez]

The rpipicow does not have the problem above, since the LED_BUILTIN is isolated from the SPI ports.

You are correct, my pico also does not have a serial interface, so using fprime-gds on a pico is not possible. Instead, I used a Teensy 4.0 to run the RadioPassthrough deployment.

I successfully got the rpipicow deployed, and can command it via the GDS.

I used the wiring pins specified in the table from a previous comment.