CM4 - code for the Cortex M4 CM7 - code for the Cortex M7 Drivers - all the HAL stuff Makefile - the make file and build area Common - one file (dualcore_boot)A quick note on "Drivers". I told CubeMX to only copy the drivers I actually need, but that ends up being quite a lot of code:
Src - 86,000 lines of code in 42 files Inc - 107,000 lines of code in 63 filesThat is 193,000 lines of code by my count, almost 200,000 lines of code. Supposedly only what I need, but I see things like usb, ethernet, i2c and plenty of other things that I am not directly using.
I am just ignoring the CM4 directories (for now). The CM7 directory looks like this:
Core/Inc - include files Core/Src - the all important main.c and some other filesThe Makefile directory looks like:
Makefile CM4 CM7Inside of "CM7" we have:
Makefile build xxx.ld xxx.sI find this layout clumsy and stupid. Why not copy all the files from Core/Src and Core/Inc into the Makefile/CM7 directory? It has always been a symptom of insanity to separate Src and Inc in this way. And why have the startup.s file here and main.c over there? Why force the user to jump back and forth. Perhaps I will fix this when I get fed up enough with it.
For the blink demo, I put these lines into the final "while" loop:
#define LED_PIN GPIO_PIN_15 HAL_GPIO_WritePin (GPIOI, LED_PIN, GPIO_PIN_RESET); HAL_Delay(200); HAL_GPIO_WritePin (GPIOI, LED_PIN, GPIO_PIN_SET); HAL_Delay(200);For the serial demo, I put these lines instead into that final "while" loop:
// This goes outside of main() unsigned char howdy[] = "Hello Cowboy!\n\r"; // This goes inside the while loop. HAL_UART_Transmit ( &huart1, howdy, sizeof(howdy), 10); HAL_Delay(1000);
openocd -f /usr/share/openocd/scripts/board/stm32h747i-disco.cfg -c "program FirstDefaults_CM7.elf verify reset" -c "exit"I start up openocd, then "gdb -tui" and it tells me that the code is in the function "Error_Handler()" in main.c where there is a endless while loop. This certainly explains why I am getting no blinking, but what could the error be? There are 5 calls to Error_Handler(). I change Error_Handler to accept an integer argument, which is copies to a int variable "error_why". I have to go find main.h and change a prototype there, then build again. I am already irritated with their directory scheme.
I make "Error_Handler" static to smoke out other calls, and indeed, there are also calls from usart.c. Back we go, jumping between the two source directories, the make directory, and the build directory. Is this stupid or what? There are 5 calls to Error_handler in usart.c.
I finally get a clean build after jumping between directories about 500 times, then I load the new code, and use gdb to examine "error_why". It is set to 1. What we see here is that it is waiting for CPU2 to boot (wake up from stop mode). This is never going to happen given that I never load code into the other core, nor are the option bytes set to try to run it. So I comment out this business and see what happens next. Actually there are two such sections with timeouts and I need to comment them both out.
Now it is still not blinking, but it is not calling Error_Handler(). It seems to be forever in the routine HAL_GetTick() in stm32h7xx_hal.c. This is a weak function that should perhaps be overwritten by something else (perhaps timer related)? A backtrace shows this being called by HAL_Delay().
I replace HAL_Delay() with my own simple busy loop delay routine. Still no blinking. gdb shows the code inside of my delay function, which is what you would expect.
This is enough for one night I guess. I cannot say that using STM32CubeMX is making my code development fast nor easy, as it claimed in the advertisement -- but I am well accustomed to being lied to in such a way. The more it told me such things, the less I believed it.
Hello Cowboy! Hello Cowboy! Hello Cowboy! ...And my delay seems to be about 1 second. So the question(s) now is/are why I cannot blink an LED via GPIO-I and why the HAL_Delay() function does not work.
0xabeaffff 0 0x0c000000 0x64000000We may have some byte order issues here. Lets ignore that for now. All 32 bits in this register do something. abea = 1010_1011_1110_1010.
00 = input 10 = alt function 01 = output (never seen) 11 = analogWhatever the case, it looks like GPIO-A has been initialized with several bits being configured for alternate functions. GPIO-I does not look like it has been initialized. PA9 and PA10 are Rx and Tx for UART1 and these do seem to be set to alternate function. (Note that PA8, PA13, PA14, and PA15 also have been set to alternate function.
PA8 is MCO1.
The question is how to get CubeMX to initialize port I for us.
Tom's Computer Info / [email protected]