F' on STM32H745Z + Azure ThreadX RTOS platform port help request

[CMLoureiro]

Dear All,

My name is Carlos and I'm currently working on a CubeSat project that will use an OBC platform based on:

• STM STM32H745Z MCU (arm cortex-m7+ arm cortex-m4)
• Microsoft RTOS Azure ThreadX + FileX
• And hopefully JPL/NASA F' framework

While a in-house developed prototype board is not available, a NUCLEO-H745ZI-Q board
is being used to get familiarised with SW and tools.

My approach to port F' to the STM Nucleo board was to use Sphinx Deployment as reference.

https://github.com/fprime-community/fprime-sphinx

For this purpose I cloned Sphinx repo and created a local development branch where, based
on the "Porting Guide" instructions :

• Created a "fprime-threadx" folder/git repo containing the toolchain, platform files and ThreadX OSAL

  Note: Log and Directory OSAL files are not yet implemented.

• Added a new FW::Types for ThreadX

• Added a new drivers folder/git repo "fprime-nucleo-q-drivers" containing the STM32 HAL files

  Note: "fprime-nucleo-q-drivers" is is essentially the same as "fprime-sphinx-drivers" plus STM32 HAL

My approach, is first to obtain a build, then replace the Sphinx HAL by the STM32 HAL and finally run the
Math Component.

• Updated the "App" to point to the new toolchain and .ini files.

Current issues:

• Adaptation of the helper file "cmake/helpers/VxWorks/VxWorksLink.py" to ThreadX equivalent.

  1. Removed processing of "ctdt.c" which seems to be related only to VxWorks.
  2. Commented out the dumping and munching processes until I find out how to implement
     them with STM32 toolchain.

Although I managed to get a "App" binary for the cortex-m7, several issues still exist, e.g. :

(...)
Linking binary...
51 | m_ftahbram_addr((volatile U32* const)IDLE_TASK_FTAHBRAM_ADDRESS),
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
arm-none-eabi-g++: fatal
shell_build_log.txt
error: input file '../../bin/stm32h745zi-cm7-threadx/App' is the same as output file
/opt/st/stm32cubeide_1.7.0/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.9-2020-q2-update.linux64_2.0.0.202105311346/tools/bin/arm-none-eabi-g++ -T /home/cmjl/Documents/FPrime/stm32/fprime-nucleo-q/fprime-nucleo-q-drivers/fprime-nucleo-q-drivers/STM32HAL/CM7/LdScripts/STM32H745ZITX_FLASH.ld -mthumb -mcpu=cortex-m7 --specs=nosys.specs -Wl,-Map=FPrime.map -Wl,--gc-sections -static --specs=nano.specs -mfpu=fpv5-d16 -mfloat-abi=hard -Wl,--start-group -lc -lm -lstdc++ -lsupc++ -Wl,--gc-sections,-print-memory-usage -Wl,--end-group -o ../../bin/stm32h745zi-cm7-threadx/App ../../bin/stm32h745zi-cm7-threadx/App ../../bin/stm32h745zi-cm7-threadx/
Checking for missing symbols...
compilation terminated.
/bin/sh: 1: Syntax error: end of file unexpected
../../bin/stm32h745zi-cm7-threadx/App |
[100%] Built target App_exe
(...)

Please find attached a shell log of the build process.

The F' changes for Nucleo board are currently sitting on my local branch. Please let me
know how could I share them, if required.

Thank you very much for your time in reading this post!

Kind Regards,
Carlos Loureiro

shell_build_log.txt

[timcanham]

@CMLoureiro I wouldn't try to adapt the script unless there are weird linker requirements. I would try the pattern that the RPI demo uses.

[CMLoureiro]

Thank you for the prompt reply. I'll follow the RPI then.

[timcanham]

This great, BTW! I would love to see a demo deployment in the Fprime community collection. If you are ready to do something like that, let us know and we can create a repo and make you the maintainer.

[CMLoureiro]

Yes, please create a repo.
Are there any procedures that need to be followed (e.g. developing the deployment, repo access,...)?
Thank you

[rawinza555]

I have been working on deploying F' on STM32 for a while now but with FreeRTOS instead of threadX. I can compiled the code just fine but still figure out what cause the code to go to the error handler. Perhaps we could help each other out.

[CMLoureiro]

Yes of course!
As for running code on the target, so far, I only ran (STM32CubeIDE environment ) the fprime/Os/test/ut/ and ThreadX OSAL

[timcanham]

@CMLoureiro Here is your repo:

https://github.com/fprime-community/fprime-azure-threadx

[CMLoureiro]

Sorry, forgot to mention that ThreadX requires the address of a TX_THREAD structure type variable as input parameter to the task/thread creation function.

[CMLoureiro]

From my limited C++ knowledge, I couldn't find a way of having such variable per object without making it static. Is there a way to achieve this?

[CMLoureiro]

@timcanham Good morning Tim,

I managed to find a way of doing the required ThreadX work without having to add extra class members by using a RTOS memory pool. Each object accesses its own data through the "POINTER_CAST m_handle" class member. So far tested it on Task and Queue objects.

[timcanham]

@CMLoureiro - Sorry, didn't get back to this. I think you have the right idea: allocate memory for the structure and then dereference it when you need it via the m_handle value.

[CMLoureiro]

I would like to add the OSAL to the repo. What is the correct procedure to follow? Do I need to branch out a work branch from "devel" and push it?
Thank you

[timcanham]

If you mean the ThreadX community repo, you are a maintainer, so you can do a PR to devel and accept it. Once it is fully tested, then you can do a release to master.

[CMLoureiro]

Yes, the ThreadX community repo. Thanks

[CMLoureiro]

Good morning Tim @timcanham ,

Since our last chat I've created a branch based on fprime-arduino "Blink" project. Currently I'm trying to get a build and later import @rawinza555 work on the STM32 drivers part.

Unfortunately I'm getting several cmake errors on the generation phase (please see attached shell log). After a few Google queries I still don't understand how to to resolve the issue...
Would it be possible for you to take a look at it?

The branch is:
https://github.com/fprime-community/fprime-azure-threadx/tree/fprime-azure-threadx-cmjl-14-01-2022-v00

Note: I'm using the same F' core baseline as used the Arduino

Many thank
shell-log.txt
s

[CMLoureiro]

@LeStarch Is there a procedure to follow when migrating a XML based component to FPP (e.g. tool to convert a Topology.cpp to a equivalent .fpp, mandatory files required,...) ?

So far I found https://nasa.github.io/fprime/UsersGuide/user/v3-migration-guide.html
Thank you

[LeStarch]

I don't know if it is written down, but here is what is possible:

Convert components first then typologies once components are done. To convert an XML file:

1. Run the conversion command

fpp-from-xml  <path/to/xml file>

2. View the output FPP file for any comments where to the tool could not convert, correct by hand.
3. Add the FPP to the CMakeList.txt file and remove the Ai.xml it is replacing.
4. Delete the Ai.xml or remove it from the project tree

[CMLoureiro]

@LeStarch Good morning,

Since our last interaction I created the initial draft for the LedBlinker Fpp based.
The source is available at the branch below and F' baseline is v3.0.0

https://github.com/fprime-community/fprime-azure-threadx/tree/fprime-azure-threadx-cmjl-14-01-2022-v00

For the moment I have 2 questions:

• Q1)

When performing the initial command "fprime-util generate" I get an error due to missing build root (please see attached error log: fprime-build-log-no-build-root.txt)
The top CMakeLists.txt file:

https://github.com/fprime-community/fprime-azure-threadx/blob/fprime-azure-threadx-cmjl-14-01-2022-v00/CMakeLists.txt

Do I miss any setting here?

Note: To be able to proceed with the build, I temporarily comment out line

message(FATAL_ERROR "No build root found for: ${DIRECTORY_PATH}") in /fprime/config/utilities.cmake - function(get_nearest_build_root DIRECTORY_PATH)

• Q2)

After proceeding as stated on Q1 I reached a point where I'm getting the following error (please see fprime-build-log_v0_18_04_2022.txt):

/home/cmjl/projects/FPrime/fprime-azure-threadx/fprime/Svc/ActiveLogger/ActiveLoggerImpl.cpp: In constructor 'Svc::ActiveLoggerImpl::ActiveLoggerImpl(const char*)':
/home/cmjl/projects/FPrime/fprime-azure-threadx/fprime/Svc/ActiveLogger/ActiveLoggerImpl.cpp:24:69: error: ambiguous overload for 'operator=' (operand types are 'Svc::ActiveLogger_Enabled' and 'Svc::ActiveLogger_Enabled::t')
24 | FILTER_WARNING_HI_DEFAULT?Enabled::ENABLED:Enabled::DISABLED;

Comparing the generated files below with the fprime/Ref ones, where the overload operators are defined, I verified that there are no differences.

ActiveLogger_EnabledEnumAc.hpp,
ActiveLogger_EnabledEnumAc.cpp,
ActiveLogger_FilterSeverityEnumAc.hpp
ActiveLogger_FilterSeverityEnumAc.cpp

Could this be due to a compiler flag?

STM32 toolchain is based on GNU 9.3.1 and my host machine has a GNU 9.4.0

Thank you very much

fprime-build-log_v0_18_04_2022.txt
fprime-build-log-no-build-root.txt

[CMLoureiro]

Hello,

• Answering my own Q2) above, I managed to overcome the error by adding a new entry "operator=" function in the Autocoders enum files below. Is there any other solution without having to change F' baseline files?

"fprime/Autocoders/Python/src/fprime_ac/generators/templates/enums/enum_hpp.tmpl"

_// ----------------------------------------------------------------------
// Operators
// ----------------------------------------------------------------------
//! Assignment operator
${name}& operator=(
    const ${name}::t& other //!< The other object
    );_

and "fprime/Autocoders/Python/src/fprime_ac/generators/templates/enums/enum_cpp.tmpl"

// ----------------------------------------------------------------------
// Instance methods
// ----------------------------------------------------------------------
${name}& ${name} :: operator=(const ${name}::t& other)
{
this->e = other;
return *this;
}

• Now I have an issue in the topology file building, on the port connections between Svc::CommandDispatcher and Svc::GroundInterface.

Svc::CommandDispatcher port "seqCmdBuff" is matched with "seqCmdStatus"and Svc::GroundInterface does not have any "Fw.CmdResponse" type port to full-fill the matched port requirement.

I was unable to find a possible solution from the online FPP user's guide or existing F' reference examples.
Could you please explain me if there's a way of overcoming this?

[ 59%] Generating NucleoTopologyAppAi.xml
fpp-to-xml
/home/cmjl/projects/FPrime/fprime-azure-threadx/NucleoBlink_Top/topology.fpp: 130.7
groundInterface.uplinkPort[0] -> cmdDisp.seqCmdBuff[0]
^
error: no match for this connection
port matching is specified here:
/home/cmjl/projects/FPrime/fprime-azure-threadx/fprime/Svc/CmdDispatcher/CmdDispatcher.fpp: 38.5
match seqCmdStatus with seqCmdBuff
^
make[2]: *** [NucleoBlink_Top/CMakeFiles/NucleoBlink_Top.dir/build.make:124: NucleoBlink_Top/NucleoTopologyAppAi.xml] Error 1

Many Thanks

[LeStarch]

The "build root" error looks like a bug in F´. We made the assumption that you would not have a module that was in the top-level folder. To fix that one, you can move Main.cpp and the register_fprime_depoloyment call into a sub folder. I'll take a look at correcting that issue.

The groundInterface issue comes from the face the groundInterface has not been updated to support the new port specification. You can switch to Deframer, or pull the command port definition in from Deframer so that it matched command dispatcher.