Newest firmware for K64F does not function correctly with binaries with lots of debug

[VeliMattiLahtela]

Jira bug

rev 0201 firmware works perfectly with the same binary, rev 0241 does not work at all.

[c1728p9]

Hi @VeliMattiLahtela, I can't reproduce this problem. I am able to program the binary you mention and then read back the contents with a debugger and they are identical. Is DAPLink showing any kind of an error message after programming?

[c1728p9]

I did some more digging, and in that image semihosting is used. Version 0201 partially implemented semihosting which is why the application worked with that version. Semihosting was never official in CMSIS-DAP/DAPLink and in version 0202 and above this code was turned off, which is why you are seeing problems (this same problem occurs in all versions other than 0201).

If you use a debugger which has semihosting support then your application will run correctly with 0241. You will also be able to see the uVisor semihosting debug statements. One debugger you can use for this is pyOCD.

[VeliMattiLahtela]

Hmmm... thats quite troublesome, as the interface that we would use to test the binary is the serial interface, and the user can't get the prompt.

[SeppoTakalo]

By lots of debug do you mean lots of serial prints? As in debug messages?
Or are you referring to actual debugging functionality?

[c1728p9]

Hi @SeppoTakalo, I think @VeliMattiLahtela, means that the image doesn't run if it is compiled for debugging.

@VeliMattiLahtela, I think it is uVisor which is using semihosting and causing this problem. As a test I would recommend rebuilding with either uVisor turned off, or uVisor semihosting turned off. You aren't using semihosting to debug a secure box are you? Just the serial port right?

[VeliMattiLahtela]

Actually I do not know, @SeppoTakalo might have the answer. I'm just the messenger here ;)

All I know is that if we want to automate some testing on those images, it is quite impossible because the serial port doesn't give a prompt.

[teetak01]

Is there some easy flag to disable the uVisor semihosting?

[c1728p9]

@meriac, is there an easy way to turn off semihosting for uVisor?

[meriac]

@c1728p9 @teetak01 Yes, just make sure to use the release build instead of the debug build of our libraries.

Currently depending on debug/release different uVisor builds are included. You could quickly verify by copying the release.a files over the debug.a files.

Famous last words: I believe uVisor is not the culprit as uVisor does not issue debug output unless its enabled in the target application. I don't know anyone actively enabling uVisor right now in Morpheus.

[c1728p9]

Hi @VeliMattiLahtela, have you tried copying the release version of uvisor? If this is cause by semihosting then I would like to close this issue.

[meriac]

@c1728p9 @VeliMattiLahtela Since months uVisor has no semihosting any more, unless it's actively enabled by a uVisor app. That is consistent for the mbedmicro/mbed version of uVisor and for the yottaized-mbed-os release.

[c1728p9]

I think this is a problem because it is a project from before morpheus. Below is the output I get when I run the binary using a debugger that supports semihosting.

Serial Port:

   _   ___ __  __               _            _  ___  ___
  /_\ | _ \  \/  |  ___   _ __ | |__  ___ __| |/ _ \/ __|
 / _ \|   / |\/| | |___| | '  \| '_ \/ -_) _` | (_) \__
/_/ \_\_|_\_|  |_|       |_|_|_|_.__/\___\__,_|\___/|___/

[DBG ][cApp]: cmd tasklet init
/>WARNING: callback 0 took 35ms
[DBG ][core]: NS Root task Init
[DBG ][sck ]: Socket Tasklet Generated
[DBG ][mle ]: MLE Tasklet Generated
[WARN][cApp]: socket_event_handler-ARM_LIB_TASKLET_INIT_EVENT
[WARN][Asck]: socket_event_handler-ARM_LIB_TASKLET_INIT_EVENT
[WARN][cApp]: network_event_handler-ARM_LIB_TASKLET_INIT_EVENT
[WARN][cApp]: cmdline_event-ARM_LIB_TASKLET_INIT_EVENT
/>WARNING: callback 0 took 47ms

Semihosting:

uVisor mode: 0
uvisor_ram : @0x1FFF0200 (8192 bytes) [config]
             (0x1FFF0200 (8192 bytes) [linker]

[meriac]

@c1728p9 See vmpu.c#L83: it's in vmpu_sanity_checks(), which is in vmpu_init_pre() . All of that code can't be ever reached because of main.c#L65.

I therefore infer an outdated version of uVisor is used here.

@AlessandroA

[AlessandroA]

Yes, this was fixed in ARMmbed/uvisor@6b5990d (Apr 1).

[c1728p9]

So can this issue be closed?
CC: @meriac, @AlessandroA, @VeliMattiLahtela

[VeliMattiLahtela]

From my point, yes. @SeppoTakalo ,client teams need to use fixed uvisor.