Oh that's great that you have a STM32F429 Discovery Board as well. Might be time to take it out and play.

I have created a new board directory called STM32F429DISC. I've just been working out of the main branch. Should I create a new one? What's the prefered process in order to contribute to micropython? (Do I need to create a github issue first?, etc)

If you don't mind holding my hand a bit on this one I wouldn't mind going through the full process. My team has baselined micropython for our specialized boards/application and we anticipate using it for the years to come. So being able to submit patches that could become mainlined will be great.

Yeah, it looks like the only 2 ways of programming this board is with the STLink or creating a custom cable for DFU mode. As part of this investigation I spent some time reading the ST Appnote AN2606 "STM32 microcontroller system memory boot mode" and there are a ton of other potential options (UART, I2C, SPI, and CAN). But the DFU seems to work well -- I also wanted to use this method since that's the method my custom boards will use.

So I normally work on a branch. It makes updating to the latest master much easier and also makes sharing your work with other developers easier (since they can set up your github repo as a remote and then switch between the branch and master. When you work on a branch you only need to rebase rather than constantly doing merges, so it makes the history much cleaner as well.https://guides.github.com/introduction/flow/

You should fork the github repository into your own account, and then add a remote for that. You'll have write permission to your forked repo. Then you can push your changes to your own repo and others will be able to see them.

Eventually, when what you have is ready, then you can do a PR from your repo to the official repo. It's probably better to do many small PRs that are each logical chunks.

I would imagine that something like creating the board definition and getting to a REPL would be a reasonable starting place.

Damien will be the one doing the actual merges into mainline (I don't have that priviledge). However, I'd be happy to help out along the way. I did most of the work in the Pins class and alot of the Timer class so I'm pretty familiar with those and most of the other stuff required for bringing a board up.

Initially, I attempted to program the board using the ST-LINK utility on windows. I believe was able to flash the firmware from STM32F407 Discovery board, but had no way find out whether it was in fact working. However, once I set up a USB cord to the OTG1 pins, I put the board into dfu mode by shorting BOOT0 and VDD and PB2 and GND, and then flashed firmware using the dfu-util (https://github.com/micropython/micropyt ... are-Update). Once I did this, the board was successfully showing up as PYBFLASH through USB on both windows and linux.

I tried once again to program it using the ST-LINK utility and confirm that it does in fact work. After doing so, the board also registered as PYBFLASH though the OTG1 pins.

As dhylands stated earlier, one can program the board using either of these methods, but the board is only discoverable as a USB device when wired through the OTG1 pins. I would like to clarify how this is done.

To do so, I used a micro USB to type-A USB cord and micro USB breakout board from SparkFun (https://www.sparkfun.com/products/12035). From the breakout board, VCC must be connected to both the 5V and PA9 pins, D- must be connected to PA11, D+ must be connected to PA12, and GND to GND. Normally, ID would be connected to PA10 as it is the OTG1 ID pin, but it is not needed in this case.

I checked the data sheet and it looks like the USB OTG HS instance (the second one, with DM/DP on PB14/PB15) can run in FS mode using the internal PHY line driver. In other words, it should be possible to get the USB VCP (the REPL) and MSD (PYBFLASH) working on PB14/PB15 without any additional hardware. A lot of the required code already exists, it just needs some attention to try it out and fix it to work correctly.

The internal SRAM is zero wait state and is arranged as 64K of CCM (accessible by CPU only - no DMA) and 3 x 64K banks (accessible by all AHB masters - (i.e. DMA))

I think that it would make sense to move the stack into CCM, and move the flash-block buffer into SDRAM. Then the flash block buffer could allow using the 128K blocks as part of the filesystem. Then there would be 192K of gc heap.

As a second stage, it would probably make sense to allow a second heap to come out of SDRAM. I'm pretty sure that SDRAM is slower, so you'd probably want to be able to control what gets allocated from where (I'm going to guess that this is non-trivial - I'm really just throwing it out as an idea).

Another, much simpler, option would be to create a non-gc heap that could be used for allocating/freeing large buffers. Using finalizers it might be possible to do a psuedo gc (i.e. have a small gc-object allocated from the gc-heap with the real memory coming from the non-gc heap). When the gc-object is reaped, it would free the object from the non-gc heap.

I searched for the github repo for the discussed code - but did not found anything. As I port micropython as well to this board I forked master into my github account and starting the board integration in the stm32f429_integration branch:https://github.com/tobbad/micropython/t ... ntegration
I added the neccessary device/board files, I changed the USB configuration to actually use the USB_OTG on Port B and allowed clock on port E, F and G. The LEDs seem to work but I do not get a USB Memory-device on CN6 connector, yet - I work on that.

I am currently fighting with USB. If I plug in the USB micro connector the host asks the device in the device for its descriptor:
GET DESCRIPTOR Request DEVICE.
The device does not return any payload and therefore the host receives a Malformed package. Therefor the device can not be discovered.
It seems like the HAL_PCD_SetupStageCallback function in usbd_conf is not called from the interrrupt handler.

Hi, I decided to give the code from badi's branch for adding the STM32F429 board support a shot and have some observations... First off, I'm not clear on whether the code is partially working on has some issues remaining, from some of the notes for changes it looked like it was at least running if not polished. My problems have occurred around connecting to /dev/ttyACM0 on Ubuntu 15.10 or W7 x64 VCP (It ended up picking the ACM driver for the Teensy which I had loaded a while back). I've tried different systems and versions of Ubuntu but it all seems pretty consistent: the device is recognized as a PyBoard in FS mode but there is only the USB endpoint for the character device, not the SCSI device for mass storage. I've tried adding the udev rules posted earlier to make sure it has 666 permissions and isn't used as a modem but it just allows me to connect without ever seeing output from the board properly (I'm using 115,200 8N1 in minicom or the default with screen /dev/ttyACM0). I can sometimes hit Ctrl-C and it will flash the LEDs back and forth a couple times to indicate the restart, and it's fairly consistent about responding to Ctrl-C or Ctrl-D characters, it's just that I never get any feedback on the screen. There was one single time I actually got what looked like buffered output from a previous minicom session with info about the MicroPython version, informational messages, responses to stuff I typed on the keyboard in the REPL, all the things I should be seeing, but I have never had a connection where it responded in real-time to input.

As a note I am using st-link with gdb to flash the elf image, and I have tried bulk-erasing the entire flash prior to flashing MicroPython but it doesn't seem to result in any differences. I found instructions for doing it this way in relation to flashing a uCLinux image I built, and the uCLinux image flashed perfectly and even initalized the LCD with a pic of Tux and a shell prompt on PC10/PC11

Could anyone provide feedback on their experiences with MicroPython on the STM32F429I eval board?

Thank you for the feedback to my branch on github. My work is - as mentioned - in the stm32f429_integration branch of my repo.

I am currently try to fix the issue related to the USB Com (or CDC) device.
These are my observations:
1. The device boots fine IF i keep it in the interpretation of a python script my modifing the default mein.py to a while-Forever loop. The device can be accessed as SCSI device if the pyb_usb_dev_init as usb_device_mode_t the USBD_MODE_CDC_MSC enum. In my github I deactivate the MSC (SCSI drive) function in the USB device for fixing the problem in the CDC (com) device.
2. Keeping the device in the python while-forever-loop you will get a /dev/ACM0 file as on the regular python board or as on the STM32F4DISCO port of the micropython.
3. Sniffing USB traffic i see that all characters which are input on the keyboard in the terminal window are forwarded to the python board. I can debug the input of the characters an everything looks OK.
4. The trouble starts with hitting CTRL-C in REPL mode. The host sends the CTRL-C over a USB_BULK out transfer to the device. As soon as this character is received, it is expected that the device sends the traceback information over a BULK_In transfer to the host. BUT on 429 I only see 16 empty Bulk In transfers which are sent with a periode of 1m - so all bulk out are sent within 16ms. After this only Interrupt In transfer is working. This effect can be seen in the attached stm32f429_CTRL_C.pcapng file (For observation open it in wireshark): CTRL-C is sent in package 26, with package 27 the described behaviour starts. For reference you can check the correct behaviour in the stm32f407_CTRL_C.pcapng file.
5. I reduced locally the application to the bare minimum CDC USB device. Therefore I added some #defines MINIMAL to the source and my own main_s.c (s=small) and a own makefile with most of the objects removed during linking. This application works fine. The behaviour with this reduced application is the same as with the regular software without the while-forever-python script activated. The device can not be recognized as circle endlessly in a device discovery cycle.

I now try to find the location of the problem by having a striped down application (main_s.c) which works and a reduced main.c:
int main(void) {
HAL_Init();
SystemClock_Config();
timer_tim3_init();
pyb_usb_dev_init(USBD_VID, USBD_PID_CDC_MSC, USBD_MODE_CDC, NULL);
while (1) {HAL_Delay(250); }
}
with all objects linked in which does not work.