Frozen flashing on TC397

[mc-cat-tty]

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)?

[daniel-veecle]

Hi! Thanks for reporting.

To be honest the setup on Linux is extremely experimental and has never been fully tested. Similarly most of our work targeted a TC375LK so the problem could be anywhere (and I don't have a TC397 board to try at the moment).

We are working to support Linux "natively" and this will hopefully improve stability (... this may take few months since we depend on Infineon's tools).

In the meantime my suggestion would be to either try with a TC375LK or try to run some example here (https://github.com/veecle/veecle-pxros) and see if those work (but the BSP target a TC375LK).

@hlehser or @annabonaldobw do you have maybe some ideas here?

[arctic-alpaca]

This can happen if Memtool fails to flash the file. I'm not entirely sure when this is the case, but I encountered it before when working on a linker script.

Can you ensure your file is flashable with Memtool in a different environment and/or with its GUI?

[mc-cat-tty]

On Windows, with a standard installation of DAS server + Memtool 2021.08.5012, I can confirm I'm able to flash it, after selecting the right target (Triboard with TC39x B-Step (DAS)).

I attach some diagnostic logging - of a successful flashing - from Memtool.

verbose_diagnostic.log minimal_diagnostic.log

As a side note, I skipped the hex generation with objcopy (let elf_data = fs::read(elf_file).context("Cannot load elf file")?; let ihex = elf_to_hex(&elf_data).context("Cannot convert elf to hex file")?;), in order to pass a hex file spitted out by tricore-elf-objcopy -O ihex Blinky Blinky.hex, by replacing the two invocations with let hex = std::fs::read_to_string(elf_file).context("Cannot read HEX file")?; and making sure I'm passing an hex file to tricore-probe instead of the ELF. Just to make sure the file I feed to Memtool is the same as the file I feed to tricore-probe.

[arctic-alpaca]

I currently don't have the hardware or setup to debug this properly, sorry.

If you want to tinker with it, changing the create_cfg to something that fits your hardware and rebuilding the docker setup with that change could be worth a try. (The docker setup internally uses tricore-windows)

[mc-cat-tty]

With some guidance I would be pleased to spend some time trying to fix it.

I'll try changing the configuration asap and then let you know.

[mc-cat-tty]

@arctic-alpaca it worked!

I changed the create_cfg under tricore-windows/src/flash.rs according to the configuration generated by a working setup of Memtool, and the flashing process succeeded.

I am now wondering if parametrizing the configuration file could be a better design. This kind of refactoring would also allow to use several different boards on the same tricore-probe setup.

Although not being a Rust programmer, I can take charge of this task, if you find it useful enough.

[arctic-alpaca]

Thank you for checking and happy to hear it works!

We are currently planning some refactoring and switching from Memtool to "Aurix flasher". In this context we also want to make it easier to use different boards. Thank you for offering to work on this, but for now it probably does not make sense to work on the Memtool implementation.

[mc-cat-tty]

Got it! Thanks for your support.