LdB-ECM / Raspberry-Pi

My public Baremetal Raspberry Pi code

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Problems when executing "mailbox_tag_message"

szoshi opened this issue · comments

Hi,
while debugging the USB application, the PiConsole_Init function calls the mailbox_tag_message function at one point to get the screen details.

I am faced with a very weird issue. When debugging the myBlinker example, the mailbox_tag_message function executes without any problem. For the USB example though, a specific asm instruction causes an exception and the system hangs. This line is:
str q0,[x29,#0xD0]
This line appears right at the top of the function if you go through the listing file (I have no optimizations during compiling as they were making my file sizes much larger for some reason and my IDE could not corelate source code and object files properly). It looks like the processor tries to push a bunch of registers to the stack at the start of the subroutine so nothing out of the ordinary.
As mentoned above, the code has no problems with the blinker example but for the USB example it just wont budge. The problem is very reproducible. I am compiling both examples with your makefile with no optimisation and with just a slightly modified linker file.
I see that the SmartStart64 files are slightly separate. Is it something in there? I am testing it on a Pi 3A+ btw.
Regards,
Szoshi

Hi,
I am afraid I have answered my own question again. After googling around I found out that the code to "Disable coprocessor traps for all Cores" in the SmartStart64 is what I needed. For the USB example though, it was part of an IF condition which is not satisfied by a compiler flag. Commenting out the IF made everything work OK.
That brings me to a more general question. Is there a version of the SmartStart64 which can work with any example? I have also noticed some race conditions with the SecondarySpin loop but did not debug it extensively. I just have a feeling that the cores run through the same code twice and thus the RPi_CoresReady variable is never that what it should be. I have found a workaround now though by simply just parking the core at wfe followed by a branch back and all seems to be okay. I guess I will pay more attention when I am doing multicore operations.
I will spend my next few days trying to get a better understanding of the USB driver and if possible extend it with interrupt transfers. I will spam this board if I am stuck at any point again :).
Regards,
Szoshi

No worries szoshi I will close the issue