It’s less than 1 months work of clutter. It gets cleaned up start of each month. 
That’s because I pushed it out of the way so I could solder some relays into that board sitting on the desk to the left.
a complex order of cleanliness
1 Like
can’t be that. Not all Justin’s boards are wireless, and there’s no extension cord running into it 
2 Likes
I’m very busy this period and can’t update code to v0.11 of TinyCLR.
In the next month will invent some spare time to go ahead with F7 boards.
1 Like
I’ve started porting to v0.12.0 but can’t get STM32F7 disco boards (746 & 769) to run with the github source code. It compiles correctly, but devices lockup.
As soon I solve the problems I will update github.
1 Like
Awesome! Thanks for your hard work!!
This time I’ve seriuos difficulties to let HS/FS USB port running, I’m wasting lot of hours but no way to run F7.
There are too many changes on USB native code and need to complete reverse eng the code.
The code as is on github is not working for me on F7. Some defines are confusing and not clear how to set. For example:
// Device.h:
#define INCLUDE_USBCLIENT
#define STM32F7_TOTAL_USB_CONTROLLERS 1
#define STM32F7_USB_PACKET_FIFO_COUNT 64
#define STM32F7_USB_ENDPOINT_SIZE 64
#define STM32F7_USB_ENDPOINT0_SIZE 8
#define STM32F7_USB_ENDPOINT_COUNT 6 // for F7xx FS endpoints are 5+1 control
#define STM32F7_USB_PIPE_COUNT 6 // ??? is that to be double the ep?
But it doesn’t work. John, please, is possible have some clarification?
Except for
#define STM32F7_USB_ENDPOINT_SIZE 64
#define STM32F7_USB_ENDPOINT0_SIZE 8
Other defines are not really important.
#define STM32F7_USB_ENDPOINT_COUNT 6 // for F7xx FS endpoints are 5+1 control
#define STM32F7_USB_PIPE_COUNT 6 // ??? is that to be double the ep?
Smallest is 2 for both defines to get USB working. They don’t need to be same.
Hi Dat, thanks for prompt reply!
the STM32F7_USB_ENDPOINT_SIZE and STM32F7_USB_ENDPOINT0_SIZE are correctly set as you show. I set STM32F7_USB_ENDPOINT_COUNT to 6 (5+1).
But memory allocation and buffer are creating problems, and mcu goes lockup. I’m using original code from github ver 0.12. I’m using F746 discovery, I’ve not implemented mods for the moment, and it doesn’t work also with standard FS usb. I’m clueless …
Yes, I see. Just don’t want you to focus on those defines.
Did you get USB FS working on STM32F7? We have UC5550 working so make sure you are same page with us in this case.
Buffer is dynamic and allocated in USBClient driver side where FS or HS no matter, and this is one of purposes of the changes.
If you can tell me where line you get lockup when creating memory, I will try to find out why with you.
@Dat_Tran I’m using github rel 0.12 master branch, but same problem also on tag 0.12.
I’m compiling code for Disco STM32F746, for FS USB. The code is original, no modification and I can’t run TinyCLR 0.12. If I set debugger to UART no problem, tinyclr run.
So this mean that USB code has some issue. Need to setup some debugging.
NOTE: If I flash working 0.10 and then I flash 0.12 USB works until power off. OMG…
If I flash working 0.10 and then I flash 0.12 USB works until power off.
=> some usb registers still remember their values if no hard reset, I guess?
I just rebuild our UC5550 without FileSystem, Graphics, SDRAM and Bootloader and starting from 0x08000000, it looks good. Without those configurations, our UCM5550 mostly same as Disco F7 board.
I also disconnected power off to make sure that all register are in reset state when power on.
Another problem can be, because USB buffer is dynamic so when USB is not active (Serial mode) there is enough memory, so the board runs. When USB is active then no more heap.
Although just few KB for USB so I don’t think it is the issue but everything can be happened, depends on how big your ram configed.
Oh very kind of you, Dat !
I guess too.
But I can’t figure out what’s wrong…
I’ve just simply adapted device.h since 0.10. I have some NO_INIT() Gpio pins to avoid st-link disconnect on SWD pins and crystals PH0-PH1 to freeze.
This is .ldf HEAP:
/************************NORMAL HEAP ALLOCATION in MCU SRAM***************************/
ER_HEAP_BEGIN 0x20009000 :
{
* (SectionForHeapBegin)
}>IRAM
ER_HEAP_END 0x2004B000 - 0x08 :
{
* (SectionForHeapEnd)
}>IRAM
/************************************************************************************/
I’ve just faced similar issue on F4 years ago, but I can’t remind what was wrong.
Check your VBus configuration also.
Does it crash or you just can not pin by USB conenction?
I checked Vbus sense and it is ok.
As you can see the MCU PC show exception area and device is “lockup”.
Are you are using
#define UART_DEBUGGER_INDEX 1
#define USB_DEBUGGER_INDEX 0
Because you can connect to tinyclr with same st-link usb port on discovery on it and this port act as uart debuger
If I use UART it works. The problem is in the native USB driver… somewhere…
1 Like