Main Site Documentation

Next step in porting: DISC0-STM32F746


Pick a led that you like, set it on inside TinyCLR_UsbClient_Acquire function where you think the problem can be to see it firmware reach to there or not.

Two simple lines below can turn a pin on or off.

STM32F7_GpioInternal_ConfigurePin(pin, STM32F7_Gpio_PortMode::GeneralPurposeOutput, STM32F7_Gpio_OutputType::PushPull, STM32F7_Gpio_OutputSpeed::High, STM32F7_Gpio_PullDirection::None, STM32F7_Gpio_AlternateFunction::AF0);
            STM32F7_GpioInternal_WritePin(pin, true);


Thanks Dat …
Ahaha, I have a function (STM32F7_DebugLed(bool onoff)) to do that, since v0.9.0. I willl start with that again…
If I can acquire USART5 (VCP troughout st-link) will be better…:disappointed_relieved:


you can open uart5 directly, just it is a bit more complex so I don’t want to drive you to another thing.


right, i don’t want to create more bugs…


I’ve compiled code for MMB (F746) and it works like a charme. No luck with Discovery F746/F769. This means that some pin is kept in wrong condition at startup and prevent USB from working going straight in lockup. Led Debug told me that Usb_Initialize is not called at all.

  • (1) In device.h, change all pins from DEFAULT() => NO_INIT()

  • (2) Put your Led Debug at end of SystemInit (STM32F7_Startup.cpp)

  • (3) If (2) is OK, put Led Debug at begin OnSoftReset (main.cpp)

  • (4) If (3) is OK, put Led Debug at the end OnSoftReset (main.cpp)

Make sure your Led Debug works separately with TinyCLR OS, because some steps above happened before gpio init and some gpio registers aren’t set in proper state yet.


I’m away for a couple of days. Anyway DebugLed shows that system_init() works fine so mcu is correctly setup. RAM is more than enough and working fine in serial debug mode. I’ve also modified Gpio_reset() func to make some tests, but no luck again. OnSoftReset() run fine from begin to end.
I feel myself really stupid, but I’m sure it is a very stupid bug … damned, for the moment it is “not found”.


OMG… I found the problem.
I set (for unkown reason) “-Ofast” as OptimizedLevel in BuildConfiguration.txt instead of “-Os”. Resetting to -Os it works fine. :zipper_mouth_face:
I’m not too confident with gcc opt flags, so I don’t really know what this can cause.


sweet, one more thing need to be kept in my mind.


Fixed the problem, now it works like charme on both USB FS and USB HS, and also USB HS + ULPI chip.


@Dat_Tran: I need your suggestion for SDRAM init. On the disco 769/746 I’d like to include SDRAM for TinyCLR heap (mainly for display). In the 0.10.0 I had SDRAM init code in the SystemInit() function. In the 0.12.0 it is not working because reset code screw up the fmc system and sdram doesn’t work.

I found that putting code in the main.cpp, main() function it works fine.

int main() {

	uint8_t* heapStart;
	size_t heapLength;

	// Note: SDRAM_DATABITS is set in device.h
	SDRAM_Init(SDRAM_DATABITS); // Init MT48LC4M32 SDRAM for heap (Databits depend on hardware implementation)

	TARGET(_Startup_GetHeap)(heapStart, heapLength);
	TinyCLR_Startup_AddHeapRegion(heapStart, heapLength);

	const TinyCLR_Api_Info* debuggerApi;
	size_t debuggerIndex;

	const void* debuggerConfiguration;

	apiProvider = nullptr;

	TARGET(_Startup_GetDebuggerTransportProvider)(debuggerApi, debuggerIndex, debuggerConfiguration);
	TinyCLR_Startup_SetDebuggerTransportProvider(debuggerApi, debuggerIndex, debuggerConfiguration);


	TinyCLR_Startup_SetRequiredProviders(TARGET(_Deployment_GetApi)(), TARGET(_Interrupt_GetApi)(), TARGET(_Power_GetApi)(), TARGET(_Time_GetApi)());

	auto runApp = true;

	TinyCLR_Startup_Start(&OnSoftReset, runApp);

	return 0;

The function _Startup_OnSoftResetDevice() is too late for heap enabling.
UCM5550 has sdram so where do you suggest to place the sdrarm init?


In my opinion, init SDARM should be in SystemInit() where you are already there.

Reset code should not reset SDRAM, except GPIO used for SDRAM. So in Device.h, find your SDRAM pins and change to NO_INIT().

Also, if you use something like GPIOEnable = GPIOA | GPIOB… should be:

GPIOEnable |= GPIOA | GPIOB....

Our InitSDRAM happened in Bootloader, meaning even before SystemInit, so if something went wrong, they should be 99% Gpio. Easy to check is, change all from DEFAULT() to NO_INIT() to test.


@Dat_Tran thank you for your help.
I’ve a lockup if I call my sdram_init in StartupInit(), but I can’t isolate the problem at the moment. I have NO_INIT for GPIO pins but I don’t think that it is Gpio_Reset() to crash FMC.

Yes I use bitwise OR to enable ports.



Use your STM32F7_DebugLed again :))


For Sure … But it tells me that SDRAM is initialized ok and can read/write fine (I write a pattern than I read it back correctly all over the address space …) also in SystemInit(), then FMC seems to crash somwhere…
If I use main() to initialize it works very fine (F746 and F769).


Hi @Dat_Tran working on F4 porting, I faced a problem in the startup.cpp code, in function

void STM32F4_Startup_GetDebuggerTransportProvider(const TinyCLR_Api_Info*& api, size_t& index, const void*& configuration) {
    TinyCLR_Gpio_PinValue value;
    auto provider = static_cast<const TinyCLR_Gpio_Provider*>(STM32F4_Gpio_GetApi()->Implementation);

    auto gpioController = 0; //TODO Temporary set to 0

    provider->AcquirePin(provider, gpioController, DEBUGGER_SELECTOR_PIN);
    provider->SetDriveMode(provider, gpioController, DEBUGGER_SELECTOR_PIN, DEBUGGER_SELECTOR_PULL);
    provider->Read(provider, gpioController, DEBUGGER_SELECTOR_PIN, value);
    provider->ReleasePin(provider, gpioController, DEBUGGER_SELECTOR_PIN);

        api = STM32F4_UsbClient_GetApi();
        index = USB_DEBUGGER_INDEX;
        configuration = (const void*)&STM32F4_Startup_UsbDebuggerConfiguration;
    else {
        api = STM32F4_Uart_GetApi();
        index = UART_DEBUGGER_INDEX;
	configuration = (const void*)&STM32F4_Startup_UsbDebuggerConfiguration; // <--- need to be added!!!
#error You must specify a debugger mode pin or specify the API explicitly.

configuration = (const void*)&STM32F4_Startup_UsbDebuggerConfiguration;
need to be added also to the case of DEBUGGER_FORCED_INDEX and DEBUGGER_FORCED_API otherwise “configuration” pointer is NOT correctly init. But this can create other problem in case of serial debug…
PS: Same apply to F7 code…


you can ignore Uart configuration for now.
If you want index,

inside GetRequiredApi(), change

return &uartApi[0];


return &uartApi[DEBUGGER_FORCE_INDEX];


Im working on Disco-F746 and I get exception:

The WriteString() calls work perfectly and text is displayed as expected. It seems that Graphics.FromHDC() return some garbage…


Graphics is a feature only available in our commercial firmwares.


Oh oh … :sob: