Author Topic: Stm32F4Discovery port  (Read 29451 times)

noyzelab

  • Team member
  • *
  • Posts: 7
    • View Profile
Re: Stm32F4Discovery port
« Reply #60 on: February 22, 2018, 06:55:07 AM »
just posting a pic of non-functioning attempt at getting this firmware going on an old board. I ended up abandoning its previous project and removing other parts.. so thought might as well try and get it used for something.

I was wondering how easy it might be to get a minimal build to see if I can download the firmware correctly. Is it possible to just get a bare board+the required usb stick and test to see if appears over USB?

I didn't get anything on the LCD, but I was hoping might see something over the USB in a MIDI app but nothing..

I dont have much/any more time to look at it for now, but thought might try and revive this thread and see if anyone else has been trying this board?
« Last Edit: February 22, 2018, 07:00:24 AM by noyzelab »

domdel

  • Team member
  • *
  • Posts: 4
    • View Profile
Re: Stm32F4Discovery port
« Reply #61 on: July 22, 2020, 04:33:40 PM »
Hi

  trying to build my own one (see attached pictures) it seems something is not going right: display does not light at all.
 
 I have triple checked all connections to be OK.
 As I have an OLED display, it needs full 5V and therefore V+ does not go through the diode next to USB connector. It does not need either V+ & GND on pins 15 & 16 neither the pin 3 needs the contrast signal.

 I have flashed the board from Linux, using the st-tools from debian.

 When connecting the Micro USB,
  • green led lights
  • red led next to micros USB lights
  • the multi-color led next to XTAL blinks red.

Therefore I have a few questions:
  • what is the boot delay ?
  • Is it normal to have the red blinking ?
  • Are there jumpers on board to change to boot ?
  • any clue about display ?
  • has anyone experienced a failed display e.g. while soldering or ... mixing up connections before fixing them ?
  • any other element that prevents from booting ?
  • Has anyone got issues with flashing through Linux ?

I am looking a ST documentation to see if it helps but I would be happy to hear from any knowledgeable person :-)
EDIT thus a question:
  • Can someone confirm the preenFM2 firmware talks to a display in 8080 mode ?
      It appears mine is using 6800 mode.
  • Has anyone already written code for a 6800 mode display ?


Regards
Dominique
« Last Edit: July 22, 2020, 07:47:36 PM by domdel »

solipsvs

  • Team Member
  • ***
  • Posts: 130
    • View Profile
Re: Stm32F4Discovery port
« Reply #62 on: July 22, 2020, 06:30:41 PM »
this is the smd board?  did you get it on some electro forum?

domdel

  • Team member
  • *
  • Posts: 4
    • View Profile
Re: Stm32F4Discovery port
« Reply #63 on: July 22, 2020, 09:21:22 PM »
Hi

 that is a STM32-f4 discovery board, following Norbim work, using his git repository https://github.com/norbim1/preenFM2. It is a fork of the standard PreenFM2 firmware to adjust to the differences one finds on that board like onboard DSP, no need for duplicating ports ...

 My issue seems to have purchased a 6800 type of display when, if I understand the code, the preenFM2 code for the LCD display (apparently not modified by Norbim) seems to address a 8080 type of communication.
  At the moment, I am trying to learn about differences and how that would alter the code.
  To start with, the Enable pin of the display works opposite : values seem to be taken into account on the descending front rather than High value.

  Whilst I am an "old" programmer, I am not familiar with "bare metal" and I look for some indications how I could tweak the code in LiquidCrystal.cpp and make it talk the 6800 dialect.

EDIT
mm well, I might have been too fast thinking I had found the cause. It seems some real PreenFM2 are using the same display (Vishjay 020N004A-GP-GPP05...) Hence my interpretation is probably wrong...

Regards
Dominique
« Last Edit: July 23, 2020, 04:20:41 PM by domdel »

norbim1

  • Team member
  • *
  • Posts: 28
    • View Profile
Re: Stm32F4Discovery port
« Reply #64 on: July 23, 2020, 10:46:53 PM »
Hi Dominique,

My version was made with an OLED display too, and it definitely needs the diode between V+ and +5V. The Disco board pins couldn't give enough high level for the OLED control, so I lowered the V+ supply a bit with the diode. Another solution would be some level shifters between the Disco pins and the OLED control pins.
I checked Your OLED's datasheet and the minimum input high level is the same as my screen: 0.8*VDD. This means that You need at least 4V, but the disco outputs only provide somewhere around 3V. The diode in the power line causes minimal brightness decrease while the input high level comes quite close to the needed value.

Norbim

domdel

  • Team member
  • *
  • Posts: 4
    • View Profile
Re: Stm32F4Discovery port
« Reply #65 on: July 24, 2020, 06:49:18 PM »
Hi

  I see: with the diode , it gets ~ 4.3V (measured) and 4.3*0.8 =3.76 V, closer to 3.3V.

  That said, beyond the display, I also probably have a USB thumb drive problem. I read in FAQs it is current with >= 4GB, I am looking for a smaller one, my smallest current is 4GB.
  Would you know the reason? Tolerance to low tension? Size not managed by software? Other ?

  If the 3V3 vs. 5V is still a problem then I will contemplate purchasing something like a device like the Ti TBX0108 to adjust.

Regards
Dominique

domdel

  • Team member
  • *
  • Posts: 4
    • View Profile
Re: Stm32F4Discovery port
« Reply #66 on: July 25, 2020, 09:47:18 PM »
Hi

  got another more tolerant display : a LCD this time (a 2004A).
  got a 2GB USB drive,
  • formatted it FAT12 with windows, --> does not work
  • Formatted it FAT 16 with Linux , does not work either

I tries with a recompiled fw 2.11, with the 2.08 that is with the sources, tried both normal and overclocked.
I use the Linux Debian 64 St-link tools for that purpose. Has anyone go positive or negative experience to share ?
I checked again a good 3 times all connections...

Nothing seems to  work :-(

Any help is welcome


EDIT
beyond likely USB key issues, I realize noting boots if I do not connect the mini USB CN1 to a computer, tested with other demo firmware.
Some people complain that depending on the ST-Link firmware, you may experience that issue... I checked the ST application for that, you do not have the choice of the ST Link firmware version, the one the application offers to upgrade to does not resolve the issue.

EDIT 2 Rebuilt a USB key, tried on crazy thing by error : re-flashed whilst on the motherboard and oh miracle: it boots, displays ...
HOWEVER : after that success: I just power it and ... nothing happens ...

@Norbim: had you to tweak anything on the BOOT0 and BOOT1 to start it ?
Do you know what ST-Link version your board has ?

I found numerous messages about recent versions of ST-Link causing that ... :-(


EDIT 3 Researching further, I found
  • if I flash the bootloader, then nothing
  • if I flash the app then OK, I assume st-link then resets from the app address ... maybe ...

Now debugging -- I needed a bootloader that compiles, as I was about to try and fix it, I remarked Xavier has issued one in 2.12-B3.
So far it seems trapped in a loop -- not sure why -- possibly because it does not look at the buttons where they are for the discovery board ? I dig deeper.

EDIT 4
Following up debugging -- admittedly not 1.11 bootloader but in that case, the difference seems minimal.
What happens :
in BootLoader.cpp, after construction of the object bootLoader in main, the test in line
  • if (bootLoader.getButton() == 0 && (*(__IO uint32_t*)magicRam != BOOTLOADER_WORD)) {
fails because bootLoader.getButton returns 8 ! even in absence of any hit button or turned encoder, therefore it goes to the loop managing menu and loops because no button push is ever detected, probably because 2.12B3 has not the patches to match the board configuration.

Once again, not exact same bootloader but a refactored one, however the logics remains.

Where does bootLoader.button get changed ?
In the bootLoader constructor, it is set to 0 but , at the end, a call to "encoders.checkSimpleStatus();" somehow sets it to 8.

I am unsure the cause is the same on bl 1.11 & app 2.11 but that is my only way to try and resolve my problem.

I continue digging and maybe will attempt to port back this version of the bootLoader to the PreenFM on Discovery board so that buttons are read properly.

@Norbim: if ever you are working at porting the whole thing to 2.12 Beta3, please let me know in case I can help or you have done it already.

EDIT 5 EURÊKA ! The situation I found debugging the 2.12 B3 bootloader could well be what I had on 1.11. I checked and the bootloader I found in git is the same as the standard preenFm2. Searching attachments in this forum thread, I found the right one, all works  !!

I will try and port 21.12 Beta nonetheless, just for fun.

Regards
Dominique
« Last Edit: July 28, 2020, 03:58:05 PM by domdel »