Porting to STM32F429, where to increase code size?

[dhylands]

I took the files from https://github.com/tobbad/micropython/t ... ntegration consolidated it into a single commit and rebased to the latest master.

My branch is here:
https://github.com/dhylands/micropython ... -discovery

I used a HW UART (UART1 - on pins PA9 & PA10) and it boots to the REPL. I haven't tried the USB stuff yet.

I flashed it using st-flash, and use this GNUmakefile: https://gist.github.com/dhylands/b6446bd55eb928103719

I wrote up a wiki page on building st-flash: https://github.com/micropython/micropyt ... g-st-flash

[dhylands]

I managed to find some USB VCP code which runs on the 429 Discovery board here:
https://docs.google.com/file/d/0B7OY5pu ... FHNE0/edit

I was able to compile and link it and if presents a CDC serial port that connects to UART 1. And sure enough I could type on UART 1 and the data shows up on the usb serial, and vice-versa. Unfortunately, this was coded using the older peripheral library rather than the HAL library, but having the full source at least means I can figure out what values are being written to what registers and I should eventually be able to figure out why the HAL version isn't working.

[badi]

You can find as well a CDC example with the latest STCube for STM32F429Disco kit in my github
https://github.com/tobbad/UsbCom
I reduced my micropython code in main.c to have a minimal CDC (No SCSCI/MSC stuff!) version which as well allows connectivity over a virtual com port. For this build I supplied the main_m. and the makefileMinimal.mk file.

But nearly the same code with the full micropython source included (the main.c in my repo and usual makefile of micropython), the CDC communication does not work.

I checked your repo and I think you missed to merge the stm32f429.ld and the stm32f429_af.csv files from the boards folder.

[dhylands]

You can find as well a CDC example with the latest STCube for STM32F429Disco kit in my github
https://github.com/tobbad/UsbCom
I reduced my micropython code in main.c to have a minimal CDC (No SCSCI/MSC stuff!) version which as well allows connectivity over a virtual com port. For this build I supplied the main_m. and the makefileMinimal.mk file.

But nearly the same code with the full micropython source included (the main.c in my repo and usual makefile of micropython), the CDC communication does not work.

Thanks I'll take a look at that as well.

I checked your repo and I think you missed to merge the stm32f429.ld and the stm32f429_af.csv files from the boards folder.

Yep - I forgot to add those files - I've now added and updated my branch. I think that the csv file can be merged with the the 405 one, but I'll do that later.

[lbattraw]

Thanks for the complete and informative reply to my last question, badi. I can understand what you're saying but I am definitely no USB expert so I wish you the best in finding a solution. Is there anything different about the 429 USB implementation vs. the 405 used on the PyBoard? They all seem to be part of the same family so I guess I'm confused what might have changed to break USB communications since I would think they would only differ in features/memory sizes rather than architectural details. I'm sure it's more complicated than that, just thinking out loud.

Are there any docs on MicroPython's memory layout as far as what lives where and why? It sounds a little complicated with all the varying sector sizes and RAM-backed storage dependency. I tried to find info in the wiki but what's there doesn't really cover it in detail, at least what I was able to locate.

Thanks to Dave for helping out too, this is great seeing the collaboration to extend MicroPython's support further!

-Larry

[dhylands]

The 405/429 has both a high speed and full speed USB peripheral. The full speed peripheral is on pins PA11 and PA12. The high speed peripheral is on pins PB14 and PB15.

On the pyboard, the micro USB connector that is exposed is connected to PA11/PA12 (the USB FS peripheral).
On the 429 discovery board, the USB connector that is exposed is connected to PB14/PB15 (the USB HS peripheral).

On the 429 board, PA11/PA12 are connected to the LCD panel (bits 4 & 5 of the red channel). On the particular package of chip that they used on the 429 discovery board (144 pin LQFP) the only pins with R4 & R5 available were PA11 and PA12, which means that its not possible to use the USB FS peripheral, since those pins are wired to the LCD.

So it means that we need to use the HS peripheral on the 429 board, where the FS peripheral was the one used on the pyboard.

[lbattraw]

Ok, that makes perfect sense, I can see how that would make it a bit more challenging trying to test and port to the '429. Thanks for the explanation, every bit helps.

-Larry

[Damien]

You may want to check the settings for the USB endpoints and their allocated buffer space. The USB peripherals have a fixed amount of RAM dedicated to the endpoints and you need to configure the address ranges for this in a header file.

[badi]

Thank you for the input. There are two #defines for buffer size on the user size APP_RX/TX_DATA_SIZE which are used for the data come or leaving the device. I don't think they have an influence as I doubled them and nothing changed (CDC/Com does not work better).

In the USB_HS hardware there is a certain amount of memory which can be split among the endpoints. Theses sizes are setup in the USBD_LL_Init in usbd_conf.c. I kept them the same as on the 405/pyboard. As I checked this I saw that in the HAL_PCD_Init->stm32f4xx_ll_usb::USB_DevInit prior to the set up of the fifos a fifo flush is done. I think it is strange to call a fifo_flush on a fifo which is not properly setup already. Further I saw that in the latest STM32Cube version 1.9 a fix in the USB_FlushTxFifo function is introduced. I merged this fix and corrected the comment of that function in my branch.

I renamed the branch of micropython were I work with reduced code to stm32f429_minimal. All interrupts except the Timer4 interrrupt and systick is deactivated (see stm32_it_m.c)). In this branch there are two build targets:
- make BOARD=STM32F429DISC DEBUG=1 V=1 -j4 : This links in nearly all of micropython code to the build-STM32F429DISC folder. With this build there is no communication to the USB-CDC device.
- make BOARD=STM32F429DISC DEBUG=1 V=1 MINIMAL=1 -j4: This only links in the HAL and the USB/timer stuff from micropython. With this version communication to the USB CDC device works.

BUT: the "make BOARD=STM32F429DISC DEBUG=1 V=1 -j4 " configuration works if the original HAL_Delay() function from stm32f4xx_hal.c is used. Somehow the __WFI() instruction has a bad influence on the communication. No idea why...

[badi]

USB_HS on STM32F4 does not like WFI (

I could reproduce the bug I hunt in the minimal USB_CDC example at:
https://github.com/tobbad/UsbCom
Google USB_HS and WFI results in some interesting links:
http://parttimeelectronics.blogspot.ch/ ... -time.html
https://my.st.com/public/STe2ecommuniti ... tviews=285
https://my.st.com/public/STe2ecommuniti ... ¤tviews=24
So i sent a online support request to STMicro. Wonder if the send an answer.

Solution seems to be here:
https://my.st.com/public/STe2ecommuniti ... tviews=469

On https://github.com/tobbad/UsbCom this works!
... and my micropython port to STM32F429Discovery works. I congratulate myself!! )
https://github.com/tobbad/micropython
branch stm32f429_integration.

I am ready to push this port to the main REPO. Who shall I ask??