Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 18:24 29 Mar 2024 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : About time the ArmmiteH7 got some TLC: V5.07.01 betas

     Page 2 of 4    
Author Message
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 12:29am 23 Jan 2022
Copy link to clipboard 
Print this post

Thanks Peter?

Would it still be possible to help me find out why your 5.07 version will not run on a STM32H743ZI ver V chip with a 25Mhz crystal, but will work on the Nucleo VI2 board with the same chip, but with 8Mhz clock from the STlink V3?

MMbasic 5.05.11 will run fine on the STM32H743ZI ver V chip with a 25Mhz crystal, so it must be some think in 5.07.0b1 that reads the version REVID = 2003 or that a Nucleo ZI2 board is being used and changes the HSE from 25Mhz to 8Mhz.

The HSE clock is defined as 25Mhz in STM32H7XX_hal.h.  But in STM32H7xx_hal_cong_h you have set it to 8Mhz.

I do agree with regarding this WeAct board and would not really want to use the silly little display or the DCMI port. It can however be bought without them but uses the 100 pin H743VI chip and a 25Mhz crystal, SPI and QSPI flash, so I still need to work out how to define whether the HSE clock is 25Mhz or 8Mhz.

Your help would be greatly appreciated.
Thanks again.
Just know enough to get me in trouble, but not quite enough to get me out.
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 08:17am 23 Jan 2022
Copy link to clipboard 
Print this post

As I said before I believe the 25MHz crystal is for the network I/F chip. Is x3 populated, this is the footprint for the processor crystal? The firmware has never supported 25Mhz only ever 8MHz. The firmware works works perfectly on my ZI but that has the Y chip. Do you have a battery installed or have you left SB156 in place? One of these is essential.
The latest firmware uses the chip version to correctly configure the chip, some of this is done by me but the HAL also has version differences and I updated the HAL in the latest releases. It could be you have some sort of bastard chip as AFAIK the ZI ws never supposed to have shipped with a V chip
 
disco4now

Guru

Joined: 18/12/2014
Location: Australia
Posts: 839
Posted: 08:53am 23 Jan 2022
Copy link to clipboard 
Print this post

  matherp said  the HAL also has version differences and I updated the HAL in the latest releases.

Does this mean just accept the update to STM32CubeIDE version 1.8.0
I am still on 1.6.0

Regards
Gerry
Latest F4 Latest H7
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 11:49am 23 Jan 2022
Copy link to clipboard 
Print this post

Thanks Peter,

My appolgies yes its a 8Mhz crystal on the ZI board that provides the HSE Clock. Got confused with another board sorry.

Yes, on the ZI2 board the HSE clock is provided by the STLink V3E as the crystal is not installed. On the earlier Nucleo ZI board with the Ver Y chip at 400Mhz an 8Mhz crystal is used. You can snap off the STLink 2 programmer end of board.

I don't use either the Nucleo ZI or ZI2 boards however. My boards use an on board 8Mhz crystal for both the Ver Y and Ver V chips.

What I can't work out is why on my boards the 5.05.11 will run on a Ver V chip which is the same 480Mhz version used on the ZI2 board, but 5.07.01b will not run.

The only difference between my boards using the Ver V chip and the Nucleo VI2 board is that I use a 8Mhz Crystal and the Nucleo VI2 uses an 8Mhz clock from the STLink V3E. I cant find any other differences.

I never have any trouble loading any of versions of firmware and I have tried using a STLink V3MINI programmer instead of the STLink 2 one I broke off a Nucleo ZI board.

Can you think of anything specific to the Nucleo VI2 board (which you say runs 5.07.01b Ok) that still allows my boards to run 5.05.11 but not 5.07.01b other than the clock source?

I have a number of boards with ver Y 400Mhz chips and a number of boards with Ver V 480Mhz chips, so it not a dodgy chip as each ver behaves the same.

NOTE Ver Y 400Mhz chips are not reliable at 480Mhz. Also all new chips manufactured will be the Ver V chip so I need to solve this issue.

Sorry I keep asking for help.
Thanks again.
Just know enough to get me in trouble, but not quite enough to get me out.
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 12:03pm 23 Jan 2022
Copy link to clipboard 
Print this post

I always remove the battery before doing any firmware install. But have tried in and out.
I use the STLink Utility not the STM32Cube programmer. But have tried both.
I have tried with the BOOT pin held high instead of low during upload that made no difference.

I tried the ArmiteH7 ver first, full chip erase, then 5.07.01b0, still no luck.
As I said it runs 5.05.11 everytime. 5.07.01b0 detects the Ver V chip, but something on my board must be different to the Nucleo ZI2 board and the only thing I can find is the different HSE clock source.
Just know enough to get me in trouble, but not quite enough to get me out.
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 03:52pm 23 Jan 2022
Copy link to clipboard 
Print this post

The later HAL library fixed a bug in the RTC drive current. One possibility is you have a higher capacitance crystal on the RTC. The Nucleo is 6pF and the firmware is targetted for that. Try reducing the load capacitors on your RTC crystal
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 12:56pm 24 Jan 2022
Copy link to clipboard 
Print this post

Thanks Peter,

My boards use 2.7pF ceramic caps on the RTC crystal and 4.7pf ceramic on the 8Mhz HSE one.

The boards work fine with 5.05.11 every time and the RTC works fine?
My boot pin is always low, PDR_ON and USB3.3 are both tied to 3.3vdc.

Unfortunately ST did not provide a Schematic for the Nucleo ZI2 board.

The STLink V3E CPU provides the 8Mhz HSE clock in the Nucleo ZI2 board.
But here is what they say.  X3 if fitted is a 25Mhz crystal.
That must be where I got the 25Mhz crystal in my head.
I think I solved it.  I will replace my 8Mhz one with a 25Mhz and change the caps too.
That is why there is the reference in hal for the 25Mhz clock.

  Quote  
- HSE on-board oscillator from X3 crystal (not provided): for typical frequencies and its
capacitors and resistors, refer to the STM32H7 Series microcontroller datasheet and to
the Oscillator design guide for STM8AF/AL/S and STM32 microcontrollers Application
note (AN2867) for the oscillator design guide. The X3 crystal has the following
characteristics: 25 MHz, 6 pF, 20 ppm. It is recommended to use
NX2016SA-25MHz-EXS00A-CS11321 manufactured by NDK.

Just know enough to get me in trouble, but not quite enough to get me out.
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 02:05pm 24 Jan 2022
Copy link to clipboard 
Print this post

  Quote  I think I solved it.  I will replace my 8Mhz one with a 25Mhz and change the caps too.
That is why there is the reference in hal for the 25Mhz clock.


The Armmite code doesn't work and cannot work with a 25MHz crystal. You must use 8MHz. Your load capacitors on the 8MHz seem very low, normally 18-22pf seems appropriate. Everything suggests that one of the oscillators isn't running.

Loading over USB or with the ST-LINK uses an external clock so these will work regardless
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 12:36pm 25 Jan 2022
Copy link to clipboard 
Print this post

Why would 5.05.11 work fine, including the RTC if one of the oscillators is not working, yet 5.07.0b1 won't run?
The new Hal with the ver V chip must recognise that a crystal is connected rather than an 8 MHz MCO.
If it is impossible to use a crystal with ArmmiteH7 on the ver V chip, I will have to provide an 8Mhz clock source I guess?
Just know enough to get me in trouble, but not quite enough to get me out.
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 01:39pm 25 Jan 2022
Copy link to clipboard 
Print this post

  Quote  Why would 5.05.11 work fine, including the RTC if one of the oscillators is not working, yet 5.07.0b1 won't run?


Because they have corrected a bug in the RTC handling in the HAL

  Quote  If it is impossible to use a crystal with ArmmiteH7 on the ver V chip,


No: it works fine on the CMM2 Waveshare board however I always recommend a crystal oscillator rather than a crystal, cheap as chips and better in every way

I'm pretty certain your issue is more likely to be the RTC. Your cap values seem very low. Normally they should be twice the crystal capacitance less a little bit for board capacitance (they are effectively is series)
Edited 2022-01-25 23:41 by matherp
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 12:47pm 27 Jan 2022
Copy link to clipboard 
Print this post

Thanks Peter,

I only had 12pf caps handy so I tried them for the RTC crystal, but it still did not start. 5.05.11 also would not start.

You are right though it is definitely the RTC that is not running. After putting the 2.7pf caps back in and installed 5.05.11 and starting OK, I got a hardware error on setting the clock.

I must of missed this before somehow, which is weird because normally I have the clock set on uploading programs??

Tomorrow I will check the other board with the ver V chip again.

I will also order some crystal oscillators I think for both the 8Mhz and the 32.768kHz.

According to the errata sheet the RTC issue on the ver Y chip was fixed on the ver V chip. It related to the LSEDRV selection bits being swapped. Selecting Medium low drive and medium high drive were swapped in the Y ver.
I presume this is what you were talking about??
Just know enough to get me in trouble, but not quite enough to get me out.
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 05:39am 25 Apr 2022
Copy link to clipboard 
Print this post

Hi Peter,
I have found some time to try recompiling a copy of the ARMmiteH7 source code you shared with me on dropbox.

I first thought I would just rebuild exactly what you shared before trying my modified version.

It appears the ff.h and ffconfig.h files in the FATFS folder that was included in ArmmiteH7 that you did share with me may not be the correct version?
#define FF_DEFINED 86606 /* Revision ID */

ff.c shows:

#if FF_DEFINED != 63463 /* Revision ID */
#error Wrong include file (ff.h).
#endif

It appears you might have sourced the correct versions from your own private dropbox directory as per the .cproject_org file which sets the directory for the FATFS folder to D:\Dropbox\STMworkspace\Armmite1.3\FATFS??

The integer.h header file also could not be found?

I am using the latest STM32CubeIDE ver 1.9.0.

Hoping you could help.
Just know enough to get me in trouble, but not quite enough to get me out.
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 08:29am 26 Apr 2022
Copy link to clipboard 
Print this post

I found copies of ff.h and ffconf.h for ver R.013 (63463) on github, but I get this error message on the build.

../Src/ff.c:552:38: error: 'TBL_DC1251' undeclared here (not in a function); did you mean 'TBL_DC950'?
 552 | static const BYTE DbcTbl[] = MKCVTBL(TBL_DC, FF_CODE_PAGE);
     |                                      ^~~~~~
../Src/ff.c:407:26: note: in definition of macro 'MERGE_2STR'
 407 | #define MERGE_2STR(a, b) a ## b
     |                          ^
../Src/ff.c:552:30: note: in expansion of macro 'MKCVTBL'
 552 | static const BYTE DbcTbl[] = MKCVTBL(TBL_DC, FF_CODE_PAGE);
     |                              ^~~~~~~
make[1]: *** [Src/subdir.mk:185: Src/ff.o] Error 1
make: *** [makefile:60: all] Error 2
"make all" terminated with exit code 2. Build might be incomplete.


Hope you can help me with the correct ff.h & ffconf.h files as the ones you had shared on Dropbox were ver R.014?
Just know enough to get me in trouble, but not quite enough to get me out.
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8516
Posted: 08:41am 26 Apr 2022
Copy link to clipboard 
Print this post

Sorry but helping build versions from source is bottom of the priority list. Unlikely to get round to this until late next week
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 10:05am 26 Apr 2022
Copy link to clipboard 
Print this post

I Changed incorrect 1251 to 437 in ffconf.h
#define FF_CODE_PAGE 437

so close still failed though???

FileIO.c:(.text.GetCWD+0x18): undefined reference to `f_getcwd'
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/FileIO.o: in function `cmd_chdir':
FileIO.c:(.text.cmd_chdir+0x1c): undefined reference to `f_chdir'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [makefile:67: Armmite1.3.elf] Error 1
make: *** [makefile:60: all] Error 2
"make all" terminated with exit code 2. Build might be incomplete.

Just know enough to get me in trouble, but not quite enough to get me out.
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 11:06am 26 Apr 2022
Copy link to clipboard 
Print this post

I fixed that problem too, I think I have ffconf.h with correct values now.

But now I get this:

collect2.exe: error: ld returned 1 exit status
make[1]: *** [makefile:67: Armmite1.3.elf] Error 1
make: *** [makefile:60: all] Error 2
"make all" terminated with exit code 2. Build might be incomplete.


What is collect2.exe??
Just know enough to get me in trouble, but not quite enough to get me out.
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 12:15pm 26 Apr 2022
Copy link to clipboard 
Print this post

If you get a chance, just add the correct ff.h and ffconf.h files to the Dropbox for me.
Thanks
Just know enough to get me in trouble, but not quite enough to get me out.
 
HardingJohn

Regular Member

Joined: 28/07/2017
Location: Australia
Posts: 78
Posted: 09:45am 28 Apr 2022
Copy link to clipboard 
Print this post

Thanks for the ff.h, ffconf.h & integer.h files

unfortunately still getting this.
this is repeated for each .o file
below is just the last set of errors for upng.o

c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x34): multiple definition of `turtle_init_not_done'; ./Src/Audio.o:(.bss+0x623c): first defined here
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x38): multiple definition of `sampledConsonantFlag'; ./Src/Audio.o:(.bss+0x6240): first defined here
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x3c): multiple definition of `com2_mode'; ./Src/Audio.o:(.bss+0x6244): first defined here
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x40): multiple definition of `com2Tx_tail'; ./Src/Audio.o:(.bss+0x6248): first defined here
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x44): multiple definition of `com2Tx_head'; ./Src/Audio.o:(.bss+0x624c): first defined here
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x48): multiple definition of `com2Rx_tail'; ./Src/Audio.o:(.bss+0x6250): first defined here
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x4c): multiple definition of `com2Rx_head'; ./Src/Audio.o:(.bss+0x6254): first defined here
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x50): multiple definition of `ScrewUpTimer'; ./Src/Audio.o:(.bss+0x6258): first defined here
c:\st\stm32cubeide_1.8.0\stm32cubeide\plugins\com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.0.0.202111181127\tools\arm-none-eabi\bin\ld.exe: ./Src/upng.o:(.bss+0x58): multiple definition of `val'; ./Src/Audio.o:(.bss+0x6260): first defined here
collect2.exe: error: ld returned 1 exit status
make[1]: *** [makefile:67: Armmite1.3.elf] Error 1
make: *** [makefile:60: all] Error 2
"make all" terminated with exit code 2. Build might be incomplete.

19:40:26 Build Failed. 349 errors, 12 warnings. (took 1m:52s.492ms)

Just know enough to get me in trouble, but not quite enough to get me out.
 
disco4now

Guru

Joined: 18/12/2014
Location: Australia
Posts: 839
Posted: 11:27pm 28 Apr 2022
Copy link to clipboard 
Print this post

John,
I have just successfully compiled this OK.
In stmcubeIDE

File/Import/Project Into workspace      (I pointed directly to the dropbox)
It should import with no issues.

Select main.c and then Project Properties. Set GCC Include paths to point to ../FATFS

In the Debug environment GCC PreProcessor section you need to change STM32H753xx to STM32H743xx. Its correct in the  Release environment.

It compiles without errors for me, 9 warnings from picojpeg.c

Regards
Gerry
Edited 2022-04-29 09:27 by disco4now
Latest F4 Latest H7
 
KeepIS

Guru

Joined: 13/10/2014
Location: Australia
Posts: 1336
Posted: 12:47am 03 Mar 2023
Copy link to clipboard 
Print this post

I have a problem.

Has anyone used a recent ( about 5 months old) H7 V2 board?

I have two H743Z12 boards that run the test code they came programmed with, the flashing LED with the blue user button cycling through the 3 LEDS.

Set the solder links as I have always done on one board.

I used STM32CubeProgrammer version V-2-13-0 to program the latest ARM H7 Basic version ArmmiteH7V5.07.01b0, I'm running this on other V1 and V2 boards.

The new boards program and verify correctly in STM32 Cube. (also did full erase)

The Problem:

I cannot get any response from MMBasic - No CMD prompt, no errors, com port is correct.

Plug in another older Board with the same Basic version and I get the CMD prompt.

I left one board exactly as it came out of the box running the test program, programmed it and exactly the same, no response from MMBasic.  

I'm using CN1 the USB/PWR port on all. The same port that STM32 Cube uses.  

I can't believe I have two new units with the same FAULT that run the test program and communicate correctly with STM Cube.
It's all too hard.
Mike.
 
     Page 2 of 4    
Print this page
© JAQ Software 2024