Stm32F4Discovery port

[Xavier]

Very nice  and totally unique
Thanks for sharing !!!

[electron libre]

Hey norbim1 and rsproduction.

Can you provide me a bit more info ow to burn the Disco board. Is there some DFU mode? Also, the I dispose is a STM32f411.

Cheers

[norbim1]

Hi, for the first time flashing:

[/quote]

Use the STM32 ST-LINK utility via the mini USB on the debugger side of the board.

http://www.st.com/content/st_com/en/products/embedded-software/development-tool-software/stsw-link004.html

Norbim

It should be STM32F407 on the board. Heere you can check the correct Discovery version:

first check the original STMicroelectronics product page to know the orginal version:
http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-discovery-kits/stm32f4discovery.html
I bought all my Discovery boards from Farnell (farnell.com). The part number is STM32F407G-DISC1.

[electron libre]

Thanks for the reply, norbim1

The STM32f411 has a different configuration, it is not an updated f407.

I made test with the board from my MidiSeq, which is an F407. I flashed, using STlink, the two files : p2_boot_1.11.bin at 0x08000000 and the p2_205o.bin at 0x08040000.

I also made some experiments attaching lcd pannels - one 4x20 and one 2x40, just to see some reaction.

Is there some step I am missing? There is noting on the LCD, should I wire all the wires and usb stick also?

I attach 2 shots with the flash process:

Cheers

[rsproduction]

Hi electron libre,

did you make the right connections btw stm32f407DISCO and LCD, did you try a contrast trimmer on the LCD 20*4?

Cheers

[electron libre]

Hello rsproduction, thanks for the reply

I wire the 4x20 LCD using the flowing schema:

pin 1 > GND
pin 2 > 5V
pin 3 > 10k pot, dividing a gnd/5V
pin 4 > PE8
pin 5 > GND
pin 6 > PE7
D0 to D3 > GND
D4 > PE9
D5 > PE11
D6 > PE13
D7 > PE15
And Backlight

The LCD Lights up, I can fix the contrast. All the charachers remain filled. Is there some step I am missing? Buttons combo, firmware activation. There is only the lsc attached, no buttons, encoders or USB memory.

My procedure of writing the bin files: first I upload the p2_boot_1.11.bin file at 0x08000000, after him the p2_205o.bin file at 0x08040000. I downloaded the files in earlier posts in this topic.

Correct me if I am wrong

Best regards

[norbim1]

Hi,
AFAIK it wont work without USB stick. 5. question in FAQ: http://ixox.fr/forum/index.php?topic=63377.0

Norbim

[electron libre]

Hello Norbim1,
After a small pause on this project I managed to get it running. I enjoy the clear FM sound and the very nice presets.

Now I have some stability issues. After a random Interval of time, from 10 to 60 secs the synth freezes. This only occurs with the 205 firmware, at least I do not remember to have it running the 106 version. The error code on the LCD is never the same. I play the sent by usb midi, USB powered. The usb voltage is about 4.5V. Is this an issue of the over clocked version?

Best regards, and thanks again for this great synth!

[norbim1]

Let's try with latest firmware. The only drawback is that in the mean time I changed my encoders, so with this they work with reverse turn direction. Either change your encoder A-B pins connections or let me know and I'll build a new .bin in a few days.

[electron libre]

Hey norbim1

After sever tests, the STM is still freezing, either playing or idle. Is there something I can do to assist you?

Cheers

[norbim1]

Hi,
I think it can be a problem with the USB stick or the power line to it (the PC number shows that it hangs on the USB OTG_FS IRQ handler). Check the USB stick, or the lines going to it. If all goes well, try to filter the power lines near the USB stick socket.

[Xavier]

The goal of this register dump is to be able to find where the firmware crashed.
I'm away from my dev computer and I don't remember exacly the steps to debug.
The PC (program counter) value is where it crashed.

With a mix of gdb, elf binary, 'layout split' or asm, and a gdb function to go to the PC value, you should get the C++ line where it crashed.

[norbim1]

Hi Xavier!

Thanks for the tip. I just checked the symbol list, and found, that at 08041AC0 there is the OTG_FS IRQ handler, and thought that the 0x28041AC0 dumped PC value can be the same with a memory mapping offset. I'll try to find it with gdb, though I only used it before to debug a connected target.

[Xavier]

Hi Xavier!

Thanks for the tip. I just checked the symbol list, and found, that at 08041AC0 there is the OTG_FS IRQ handler, and thought that the 0x28041AC0 dumped PC value can be the same with a memory mapping offset. I'll try to find it with gdb, though I only used it before to debug a connected target.

Yes RAM adress in the STM32F4 is 0x20000000. So this is the same adress moved into MCU RAM !

[norbim1]

Hi electron libre,

Hi,
I think it can be a problem with the USB stick or the power line to it ....

by further analyzing the code I realized that the USB_FS_Core is responsible for the computer connection side, so You should check the PC USB connection instead. It can also be a USB power issue.