Currently under linux we use a pregenerated version of the MCD bindings. Even though the MCD library can currently only be used under windows, this allows to develop the library under linux as well.

I quickly prototyped it, and in contrary to this setup (and what I initially believed) it should be possible to generate the bindings through a builds script even in linux, so we could get rid of the pregenerated version of the bindings.

We have to to investigate the compability overall, because in the end it must compile under windows and should compile in linux. E.g. I had some issues regarding the signedness of enum { ... }; definitions.

I'm opening this issue to report that, while trying to flash on a TC397 board, the flashing process hangs indefinitely.

Details about my environment:

uname -sm

Linux x86_64

Which implies docker backend.

./target/debug/tricore-probe [...] --log-level trace

[...]
INFO  tricore_windows::flash <- docker] Spawned Infineon Memtool to flash hex file

Listing devices:

Found 1 devices:
Device 0: "DAS JDS TriBoard TC397 V2.0 TB7RWQK8"

I do not have edited Memtool configuration in any way. Am I supposed to do it or should be automatically managed (like in create_cfg function for Windows backend)?

I followed the link to download the project, and then installed the tools according to the instructions in GitHub.
https://github.com/veecle/tricore-probe?tab=readme-ov-file#requirements
The following error occurred when compiling:

Since the tricore rust toolchain is based on the LLVM backend the tools objcopy and addr2line from the LLVM toolchain should be used
rename:

• objcopy -> llvm-objcopy
• addrline -> llvm-addr2line

The current MCD bindings only contain anonymous enumerations. This converts all variants to constants which make it hard to manage and use in rust. With a bit of preprocessing of the header file, bindgen could be able to produce rust enumerations, e.g. compare

Check therealfrauholle@55ba686 for a prototyped implementation. I preprocessed the headerfile manually (actually, with a regex); I believe this should actually happen within the buildscript and we should not touch the header files directly.

What we need to see is how we implement the usual custom and reserved variants, which were manually implemented for McdReturnError. Check the equivalent definition of mcd_return_et. These variants are not actually rust variants, but boundaries for custom variants. Three options we have, which are all good:

1. Do not handle these variants - which is acceptable because there will never be variants in the "custom" range. To my understanding, this is meant to be used by users of the library to use the same type in their code, thanks to rust we don't have to do that. It is acceptable because it is unlikely that we ever encounter a "reserved" error code.
2. Build a derive macro that derives something allong the following trait:

/// Error code completely unknown, should never be reported by MCD
struct UnknownCode;

/// Codes that MCD can report but we can't really handle
enum McdUnhandledCodes {
   Reserved(u32)
   Custom(u32)
}

trait UnhandledCodes {
    fn try_from(code: u32) -> Result<Result<Self, McdUnhandledCode>, UnknownCode>;
}

The final enumerations would still contain e.g. the _RESERVED_LO and _RESERVED_HI variants, which is not perfect.
3. Keep a manual definition of enumerations in sync in the rust library. This is somewhat tedious, manual work but it would only have to be done once and with better binding generation this will be much easier than it already is.

In rust_mcd::raw we started to build strong(er) typed variants of the native, unsafe MCD functions. We want to refactor all calls into the library that happen outside of this module into that module.

I built some blinky examples with HighTec Rust Aurix compiler version 1.0.0 for the TC375 lite kit board. I am trying to run these elfs on my board via tricore-probe but I face this error:

PS C:\Users\andra\git-repos\tricore-probe> cargo run -- .\blinking_led_1_litekit.elf -l trace
    Finished dev [unoptimized + debuginfo] target(s) in 0.08s
     Running `target\debug\tricore-probe.exe .\blinking_led_1_litekit.elf -l trace`
[2024-04-22T12:43:23Z TRACE tricore_windows::das] Starting dashpas
[2024-04-22T12:43:23Z TRACE tricore_windows::das] Starting UDAS_Console
[2024-04-22T12:43:23Z INFO  tricore_windows::das] DAS server started
[2024-04-22T12:43:24Z DEBUG rust_mcd::library] Initializing MCD library
[2024-04-22T12:43:24Z DEBUG tricore_probe::chip_interface] Connecting to any available device
[2024-04-22T12:43:24Z INFO  tricore_probe::chip_interface] Converting elf .\blinking_led_1_litekit.elf to hex file
[2024-04-22T12:43:24Z INFO  tricore_probe::chip_interface] Flashing hex file
[2024-04-22T12:43:24Z TRACE rust_mcd::connection] Scanned for servers, found Connection { servers: [ServerInfo { acc_hw: "DAS JDS AURIX LITE KIT V2.0 (TC375) LK7KFCF1", server: "UDAS", system_instance: "" }] }
[2024-04-22T12:43:24Z INFO  tricore_windows::flash] Spawned Infineon Memtool to flash hex file
[2024-04-22T12:43:26Z INFO  tricore_windows::flash] Infineon Memtool terminated successfully
Error: Elf file does not have _SEGGER_RTT symbol
error: process didn't exit successfully: `target\debug\tricore-probe.exe .\blinking_led_1_litekit.elf -l trace` (exit code: 1)

I assume this means I need to utilize the rtt-target crate somehow. Do you have some examples for that (preferably with the Lite Kit board)?

Currently the user must supply an elf path when listing devices. This argument is actually not used, the tool will exit after listing devices and can actually be a path not pointing to a file.

See therealfrauholle@f95ac87 for a reference, e.g. a hack that could solve this. This could already solve the problem, but we want to use clap to its full potential to nicely reflect the usage of elf path in the CLI.

We should add some instructions in the readme on how to install this (i.e., cargo install --git https://github.com/veecle/tricore-probe). Thoughts?

@therealfrauholle?