Pages: 1 [2] 
|
 |
|
|
Author
|
Topic: Controller F7 oder H7 (Read 6480 times)
|
|
DF8OE
Administrator
 Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
 
|
 |
Re:Controller F7 oder H7
« Reply #15 on: 03. March 2018, 09:18:16 »
|
|
Hallo Thomas,
nochmal ganz klar:
Es ist nicht sicher, ob wir den genannten "read-RAM-Bug" in unserer Konstellation haben. Und wenn, ist nicht gesagt, ob der Workaround in unserer Konstellation zu einer Reduktion der Geschwindigkeit führt.
Das kann man aber rausbekommen: indem außer Danilo, Gerd DF9TS und mir noch ein paar ein Board mit dem H7 aufbauen.
Soweit ich das Errata gründlich genug überflogen habe ist dieser Bug der einzige, der für uns relevant ist. Und es ist kein KO.
Ich werde auf jeden Fall ein H7 Board zum "Forschen" aufbauen.
EDIT:
Und mein RF-Testaufbau lässt einen Tausch der UI-Platine in Sekunden zu. Ich könnte (und werde) also die H7 Variante mittesten.
vy 73
Andreas
|
| « Last Edit: 03. March 2018, 09:19:55 by DF8OE » |
 Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Controller F7 oder H7
« Reply #16 on: 08. July 2018, 20:12:13 »
|
|
Hi,
instead of opening a new topic, I just use this one as it fits to my news:
I have finally convinced the STM32H7 to have USB working so that it is detected by my PC. It required figuring out what goes wrong (the USB core peripheral reset was not working because the USB core clock configuration was not working). I still have no idea why the clock configuration code generated by the ST Tool CubeMX does not work, but at least the workaround I found is working for now.
This was the last piece I want to get working before we can start testing. Please note, I am still using the buggy STM32H743 rev Y (rev id 0x1003). There is a new revision X ( rev id 0x2001) according the errata sheet so I don't know if the problem I experienced is in the code or is a silicon bug (which I honestly doubt, other should have had the same issue then).
It is still not time to celebrate or to start unsoldering the STM32F7. Right now the F7 is still the better choice (it has a working flash configuration backup, it as working bootloader, it has enough power, it is well tested). But the future might provide us with a use case for the H7 and then we are ready...
Zusammenfassung auf Deutsch: Beim STM32H7 habe ich einen wichtigen Schritt geschafft, USB geht jetzt soweit, das ich es testen kann.
All is published: See https://github.com/db4ple/mchf-github , branch ovi40h7 (NOT the h7 branch!)
73
Danilo
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Controller F7 oder H7
« Reply #17 on: 09. July 2018, 08:30:52 »
|
|
Hi,
just to update my last post: Now that I know what was not working and used this as search term (PLL3Q for those interested) , I was able to find posts explaining the problem (It is a bug in the STM HAL 1.2.0) and the post even included a fixed code. The issue could have affected other parts of the system as well, it was kind of "luck" that it was just the USB.
I have also verified that USB is indeed working correctly. I was able to receive via HDSDR. due to missing finals on the used rf board could not really test transmitting but there is no reason why this should not work.
So far all looks good now.
Next steps are to port and test the bootloader code. Due to a completely changed flash memory sector layout the bootloader memory size will be changed/increased (all sectors are now 128k, before the bootloader was 32k in 2 sectors of 16k). Currently use of flash for configuration storage is disabled, for the same reason. The configuration memory would occupy 2x128k flash (before it was 2x16k).
This sums up to 384k space (3x128k) as opposed to 64k on the F7 and F4.
This is not a real problem as long as we have EEPROM on all OVI40 boards. It just removes the ability to backup the EEPROM in flash and restore it from there. And we finally will get this back working, it is just not a simple "recompile" on the new H7 processor.
Once all of this is done, the H7 port will be part of the main development branch active-devel in the "official" df8oe repository.
For those with a H7 board: I will not distribute binaries, please either build and flash using the ST link for yourself from my (!) github repository , see last post; or wait until we integrate this into the main development, from this on we will also provide binaries for the H7 through the usual means.
73
Danilo
|
|
Logged
|
|
|
|
Pages: 1 [2] 
|
|
|
|
|
|
|
