TinyCLR porting update to 1.0.0

TinyCLR OS
1

I’ve started porting some boards to v 1.0.0 of TinyCLR. For the moment I’ve ported Nucleo-F767, Disco-F769, ULPI and USB HS. Next week I will port some F4xx boards, like Disco-F429 and Mikroe MMB.

Still no way to let run the F746 chip (MMB F746 and Disco-F746). It lockup but I can’t figure out the issue. It happens somewhere in the TinyCLR libs.
Github : Github

7 Likes
2

similiar situation was to port for Nucleo STM32F411RET6 i don’t know issues why

i face now two situations :

- if I use pins for SPI
(PA5 = SCK pin D13, PA6 = MISO pin D12,PA7 = MOSI pin D11) do not work
also
if i use
#define UART_DEBUGGER_INDEX 1 automatically it eat ram memory
and i can not use even resolution of 160x20 pixel on ST7735

so only way to test it was through using devices with their protocols (I2C,SPI,UART …) so

  • for i2c i test i use display ssd1306 and
  • for spi i test i use display stt7735

but before test
i make sure did work with Arduino IDE (STM32 Devices)

  • so in this way i know if problem with device or tinyclros (in my case :D)
3

@valon_hoti_gmail_com be aware that in the STM32Fx_Startup.cpp in function STM32Fx_Startup_GetDebuggerTransportApi() code there’s a bug:

…
#elif defined(DEBUGGER_FORCE_API) && defined(DEBUGGER_FORCE_INDEX)
api = DEBUGGER_FORCE_API;
#else

But need to set:

#elif defined(DEBUGGER_FORCE_API) && defined(DEBUGGER_FORCE_INDEX)
  api = DEBUGGER_FORCE_API;
  configuration = (const void*)&STM32F4_Startup_UsbDebuggerConfiguration;
#else

otherwise the UDB Debugger configuration struct is never initialized, mostly crashing firmware.

1 Like
4

but in my case is to use deploy/debuger through (ST-LINK USB on Nucleo) which act as UART not as USB

5

Oh I see… I will test SPI for my Nucleo-144 F767. But last preview it was working fine. I’ve no idea about UART debugging, but are you sure that index 1 point to a valid USART in the device.h?