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

[capsulecorplab]

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.

Re-installed baremetal-size from the updated branch, but getting a different Traceback error now. I'm currently installing the ARM cross-compile tools with apt; should I be installing with arduino-cli? Also, there's a typo in the size-utility branch; it's currently size-utilility

[capsulecorplab]

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.

How do I switch to a different SPI port on the Teensy 4.1?

[capsulecorplab]

Also, I'm reading in the Teensy documentation that the serial port doesn't actually become available until after it's been flashed/programmed (according to https://www.pjrc.com/teensy/td_serial.html and https://www.pjrc.com/teensy/troubleshoot.html), which would explain why my Teensy 3.2 shows up as /dev/ttyACM0 (since I've previously programmed it via the Arduino IDE), but not my Teensy 4.1.

[capsulecorplab]

Just tried add SPI.setSCK(14); before rfm69.init(): in RFM69.cpp and attempted to build and upload the RadioPassthrough.hex to my Teensy 3.2. Should I be seeing chatter on the serial port?

[ethancheez]

Just tried add SPI.setSCK(14); before rfm69.init(): in RFM69.cpp and attempted to build and upload the RadioPassthrough.hex to my Teensy 3.2. Should I be seeing chatter on the serial port?

There should not be chatter with the RadioPassthrough by itself. You should only see chatter if you have the BaremetalReference talking to your RadioPassthrough.

Is the LED blinking though?

[ethancheez]

Re-installed baremetal-size from the updated branch, but getting a different Traceback error now. I'm currently installing the ARM cross-compile tools with apt; should I be installing with arduino-cli? Also, there's a typo in the size-utility branch; it's currently size-utilility

Yes, I based the baremetal-size script on what the arduino-cli installs. You don't have to run the script anymore, that was more of a way to debug as to why the teensy32 was not blinking.

And yeah, I noticed the size-utility typo yesterday too. Oops 😆

[capsulecorplab]

Is the LED blinking though?

LED is not blinking :slightly_frowning_face:

[ethancheez]

Is the LED blinking though?

LED is not blinking 🙁

Try upload the BaseDeployment deployment and see if it blinks

[capsulecorplab]

Is the LED blinking though?

LED is not blinking 🙁

Try upload the BaseDeployment deployment and see if it blinks

Still no luck :slightly_frowning_face:

[ethancheez]

How do I switch to a different SPI port on the Teensy 4.1?

Following the Teensy 4.1 pinout: This will be your new wiring pins for SPI1:	RFM69HCW	Teensy 4.1
MISO	1
MOSI	26
SCK	27
CS	0
RST	4
G0	3

Then in your RFM69.hpp you have to include #include <RHHardwareSPI1.h>, modify the pin numbers in RFM69.hpp, and then in RFM69.cpp:20, change to rfm69(RFM69_CS, RFM69_INT, hardware_spi1)

[capsulecorplab]

I only see pin numbers for CS and RST in RFM69.hpp

[ethancheez]

I only see pin numbers for CS and RST in RFM69.hpp

The hardware_spi1 argument sets the MISO, MOSI, and SCK pins internally by the library. The only pins you would have to change in RFM69.hpp are the CS, INT, and RST pins.

Edit: Forgot to mention that G0 is the INT pin

[capsulecorplab]

Here's my diff; Does this look right?

[ethancheez]

Here's my diff; Does this look right?

Yup! Looks good. I never actually tested this using BaremetalReference, but I did something similar in another CubeSat project I am working on here. Uses an RFM23 instead, but the same RadioHead library.

And that deployment successfully works for the Teensy 4.1.

[capsulecorplab]

Encountered a build error :slightly_frowning_face:

[ethancheez]

Oops I missed one small detail. Add this following line in lib/arduino/CMakeLists.txt:

"${CMAKE_CURRENT_LIST_DIR}/RadioHead/RHHardwareSP1I.cpp"

So it should look like:

string(FIND "${FPRIME_TOOLCHAIN_NAME}" "teensy" index)
if (NOT index EQUAL -1)
    set(SOURCE_FILES
        "${CMAKE_CURRENT_LIST_DIR}/RadioHead/RH_RF69.cpp"
        "${CMAKE_CURRENT_LIST_DIR}/RadioHead/RHHardwareSPI.cpp"
        "${CMAKE_CURRENT_LIST_DIR}/RadioHead/RHHardwareSP1I.cpp"
        "${CMAKE_CURRENT_LIST_DIR}/RadioHead/RHGenericSPI.cpp"
        "${CMAKE_CURRENT_LIST_DIR}/RadioHead/RHGenericDriver.cpp"
        "${CMAKE_CURRENT_LIST_DIR}/RadioHead/RHSPIDriver.cpp"
    )

    add_library(RadioHead ${SOURCE_FILES})
    target_include_directories(RadioHead PUBLIC "${CMAKE_CURRENT_LIST_DIR}/RadioHead")
endif()

Note the typo here too, it is intended because the one who wrote the RadioHead library made a typo.. It is SP1I not SPI1. The 1 and I are flipped lol

[ethancheez]

Also may I ask where you got your Teensy 3.2? I have wanted to get one for a while but it appears to be discontinued.

[capsulecorplab]

Also may I ask where you got your Teensy 3.2? I have wanted to get one for a while but it appears to be discontinued.

Microcenter in Tustin, CA, a long time ago (I want to say circa 2015 :sweat_smile: ).

[capsulecorplab]

Build works! It's hanging on the upload process though (there's a persistent dim red LED light after I hit the program button)

[ethancheez]

Build works! It's hanging on the upload process though (there's a persistent dim red LED light after I hit the program button)

Try click on the Auto button in that Teensyduino GUI

[capsulecorplab]

Clicked. Red LED's still persistent :confused:

[ethancheez]

Clicked. Red LED's still persistent 😕

Hmm.. Has your Teensy been programmed before? Do you think this is related to you not being able to view the serial port /dev/ttyACM0 of your Teensy 4.1?

[capsulecorplab]

Clicked. Red LED's still persistent 😕

Hmm.. Has your Teensy been programmed before? Do you think this is related to you not being able to view the serial port /dev/ttyACM0 of your Teensy 4.1?

I may've previously tried flashing the fprime Arduino blinker (with no recollection of it working) and the earlier attempt to flash the baremetal reference. Otherwise, it hasn't been programmed. I suspect if it was successfully programmed, the serial port would become available as the documentation suggests

[ethancheez]

Clicked. Red LED's still persistent 😕

Hmm.. Has your Teensy been programmed before? Do you think this is related to you not being able to view the serial port /dev/ttyACM0 of your Teensy 4.1?

I may've previously tried flashing the fprime Arduino blinker (with no recollection of it working) and the earlier attempt to flash the baremetal reference. Otherwise, it hasn't been programmed. I suspect if it was successfully programmed, the serial port would become available as the documentation suggests

Are you able to flash it with a simple blink program through the IDE first?

[capsulecorplab]

No luck via the Arduino IDE

Odd, could it be a faulty Teensy?

[ethancheez]

No luck via the Arduino IDE

Odd, could it be a faulty Teensy?

oops my bad accidentally edited comment instead of quoting.

Could it be a faulty teensy?

[capsulecorplab]

Could it be a faulty teensy?

I doubt it, because it blinks when I plug it in and the IDE was able to recognize it on a port

[ethancheez]

Which version of Ubuntu are you running in your environment?

And just to make sure you have the 00-teensy.rules under /etc/udev/rules.d/? I do see it in your setup here

What if you also try to add the rules file in /lib/udev/rules.d/?

[capsulecorplab]

Which version of Ubuntu are you running in your environment?

Ubuntu 22.04 (Jammy)

And just to make sure you have the 00-teensy.rules under /etc/udev/rules.d/?

Yup, added rules file to /lib/udev/rules.d/ too

[ethancheez]

Hmm sorry I am pretty stumped and unsure why your Teensy isn't programming.

I'm googling around and one post mentioned that error you're getting appears when the Teensy is in a "bad state" after uploading a corrupted hex file (or something similar).

I do recall I ran into that error before a long time ago, preventing me from uploading hex files to my Teensy 4.1. If I remember right... I just kept trying to upload the example Blink.ino program while pressing the program button at the same time until it finally overwrites. And then I can use the Teensy normally afterwards. Unsure if this will work in your case though.

You said your Teensy is currently blinking? Do you know if the blinking is the new Blink.ino binary or an old program? Maybe you can change up Blink.ino a little to see if it is actually uploading or not. (e.g. change the delay, add print statements, etc.)

[ethancheez]

I verified that using SPI1 on the Teensy 4.1 works, using the changes from this comment. I can command it (turning on/off LED) and can visually see it start/stop blinking.

Here is my setup. I am using a Teensy 4.1 (top) running BaremetalReference and a Teensy 4.0 (bottom) running RadioPassthrough. The GDS is listening to the Teensy 4.0 port. I had to disable the LedBlinker on the Teensy 4.0 since it interferes with the SPI bus.

fprime-gds -n --dictionary BaremetalReferenceTopologyAppDictionary.xml --comm-adapter uart --uart-device /dev/ttyS5 --uart-baud 115200

Edit: This is what I see in the serial monitors of both Teensy boards:

Teensy 4.1 (BaremetalReference)

Teensy 4.0 (RadioPassthrough, disconnected from the GDS)

Also, as a way of knowing if your Teensy 4.0 is receiving anything through the radio, the LED will actually blink because it is attached to the SPI clock. If the radio receives a packet, the clock goes to HIGH logic, which will also enable the LED.

[capsulecorplab]

Update: I managed to flash a basic Arduino blink sketch onto my Teensy 4.1 from the Arduino IDE 2.2.1 installed on my host machine, but still can't seem to do so from within my virtual environment, so that at least confirms the Teensy 4.1 isn't busted.

[capsulecorplab]

I suspect it could be a port binding issue (perhaps with one of the /dev/hidraw* ports)

[ethancheez]

Update: I managed to flash a basic Arduino blink sketch onto my Teensy 4.1 from the Arduino IDE 2.2.1 installed on my host machine, but still can't seem to do so from within my virtual environment, so that at least confirms the Teensy 4.1 isn't busted.

That's nice to hear. Perhaps the mounting of the HID device isn't set up to your docker container?

Edit: didn't see your comment afterwards before i wrote this one 😅

[capsulecorplab]

Update: I managed to flash a basic Arduino blink sketch onto my Teensy 4.1 from the Arduino IDE 2.2.1 installed on my host machine, but still can't seem to do so from within my virtual environment, so that at least confirms the Teensy 4.1 isn't busted.

That's nice to hear. Perhaps the mounting of the HID device isn't set up to your docker container?

Edit: didn't see your comment afterwards before i wrote this one 😅

Yeah, I'm running a docker system prune to reset my container and adding a /dev/hidraw0, /dev/hidraw1, /dev/hidraw2, and /dev/hidraw3 to the list of devices in my docker-compose.yml before attempting to re-create/re-run the container to see if that might fix it

[capsulecorplab]

Yeah, I'm running a docker system prune to reset my container and adding a /dev/hidraw0, /dev/hidraw1, /dev/hidraw2, and /dev/hidraw3 to the list of devices in my docker-compose.yml before attempting to re-create/re-run the container to see if that might fix it

No luck :slightly_frowning_face:

[ethancheez]

Yeah, I'm running a docker system prune to reset my container and adding a /dev/hidraw0, /dev/hidraw1, /dev/hidraw2, and /dev/hidraw3 to the list of devices in my docker-compose.yml before attempting to re-create/re-run the container to see if that might fix it

No luck :slightly_frowning_face:

I'm not very familiar with docker containers and mounting devices in it.

I found this repo that seems to have successfully programmed a teensy within a container.

[ethancheez]

I got my hands on a Teensy 3.2 and deployed both BaseDeployment and BaremetalReference on it. The LED blinks. Still have to test it with the radio and fprime-gds in the loop. Will update when I get that set up.

[ethancheez]

Update: I got Teensy 3.2 BaremetalReference talking to a Teensy 4.0 RadioPassthrough and can command it via GDS. I had to increase the data rate of the radio because the Teensy 3.2 clock speed seemed too slow to keep up with the SPI clock, causing checksum errors with fprime's Deframer component.

rfm69.setModemConfig(RH_RF69::ModemConfigChoice::GFSK_Rb250Fd250);

[capsulecorplab]

Update: I got Teensy 3.2 BaremetalReference talking to a Teensy 4.0 RadioPassthrough and can command it via GDS. I had to increase the data rate of the radio because the Teensy 3.2 clock speed seemed too slow to keep up with the SPI clock, causing checksum errors with fprime's Deframer component.

rfm69.setModemConfig(RH_RF69::ModemConfigChoice::GFSK_Rb250Fd250);

Cool! I just managed to flash a Teensy 4.1 using the teensy docker container. Will try it on my 3.2 as well...

[capsulecorplab]

Update: (I think) I managed to flash the baremetal reference onto the Teensy 4.1 from within my vm! The trick was that I had to connect and spin up the vm with the Teensy already in programming mode, or else it wouldn't recognize it.

Still having issues communicating with it through fprime-gds

Though, I'm getting symbols show up in minicom

[ethancheez]

Still having issues communicating with it through fprime-gds

Though, I'm getting symbols show up in minicom

You can't have both minicom and the gds open I believe. Try get out of minicom, and rerun fprime-gds

[ethancheez]

Actually I realized, what are you running fprime-gds on? The BaremetalReference or RadioPassthrough?

In that case you can have minicom open for the BaremetalReference. fprime-gds should be for the RadioPassthrough

[capsulecorplab]

Actually I realized, what are you running fprime-gds on? The BaremetalReference or RadioPassthrough?

In that case you can have minicom open for the BaremetalReference. fprime-gds should be for the RadioPassthrough

I'm running it on the BaremetalReference, but I also killed fprime-gds before running minicom - I just happened to still have the browser tab open

[ethancheez]

Actually I realized, what are you running fprime-gds on? The BaremetalReference or RadioPassthrough? In that case you can have minicom open for the BaremetalReference. fprime-gds should be for the RadioPassthrough

I'm running it on the BaremetalReference, but I also killed fprime-gds before running minicom - I just happened to still have the browser tab open

The fprime-gds does not directly connect to BaremetalReference. BaremetalReference talks to RadioPassthrough which then talks to fprime-gds

[capsulecorplab]

So, I managed to find another Teensy 4.1 (I forgot I had actually bought two) and flash the RadioPassthrough onto it, though still no luck running fprime-gds.

I noticed in your wiring in https://github.com/fprime-community/fprime-baremetal-reference/issues/13#issuecomment-1842168926 that SCK isn't connected on pin 13 on your Teensy 4.1. Should I be doing the same?

EDIT: the left Teensy flashes a on for about `10 seconds and flashes off for ~10 seconds, while the right Teensy flashes on/off every second

[ethancheez]

I noticed in your wiring in #13 (comment) that SCK isn't connected on pin 13 on your Teensy 4.1. Should I be doing the same?

Yeah Pin 13 cannot be used as both LED Blinker and SCK. So I remapped the pinout for the Teensy 4.1 to use SPI1 instead, with the pinouts from this comment.

fprime-gds is not connecting probably because the BaremetalReference radio is failing to send, due to the SPI clock being interrupted by the LedBlinker, and thus the RadioPassthrough is not receiving any packets.

[ethancheez]

If you minicom into the RadioPassthrough, see if you are receiving any bytes. It will be a bunch of randomness (boxes, '?', letters, numbers, etc.). If so, that means your RadioPassthrough is getting packets.

[capsulecorplab]

If you minicom into the RadioPassthrough, see if you are receiving any bytes. It will be a bunch of randomness (boxes, '?', letters, numbers, etc.). If so, that means your RadioPassthrough is getting packets.

Disconnected SCK pins and tried running minicom, but screen remains blank :confused:

[ethancheez]

Are any of the LEDs blinking? Is the RadioPassthrough LED blinking more frequently now?