Other Parts Discussed in Thread: SYSCONFIG
hi
I used gpio to drive high when the board first started.
But like the graph, there are times when you run high and go down low once in a while.
Why is that?
sysconfig 1.18.0
mcu+ sdk for am263x 9.1.0.41
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello Gyeongju,
Which I/O are you configuring as the output pin?
Is the problem re-creatable every time you run the program? Or if not, do you have a set of steps that will reliably re-create the issue?
Have you tried using breakpoints to identify at which point during program execution you are seeing the dip?
Also is this on a custom board or a TI EVM? If a custom board, what is the I/O tied to?
Best Regards,
Ralph Jacobi
Hello Gyeongju,
Okay that gives us a starting point but with this being observed on your developed board I have a very slim amount of information to work with here... the problem statement is clear, but I don't have any immediate idea on what's going wrong just based on the information provided.
I'm using pin c14, A15, A14, A13
Is the same behavior observed on all 4 lines? What are those lines connected to on your board?
When I tested it, I found a problem with the MCSPI_init() function.
Can you elaborate more by what this means? The above pins don't correlate to any SPI interface so it's not clear how these might be related.
Can you share your SysConfig for this project to review pin mux etc?
Best Regards,
Ralph Jacobi
hi
Four pins are the same
I don't know why, but if I change the location of GPIO_init(); MCSPI_init(); the gpio doesn't go low
Hello Gyeongju,
So I couldn't properly load your SysConfig file in because of the custom parameters in it, but I was browsing through the text data regarding the relevant pins. It looks like all of them are connected to external devices, so this leads back to my prior question of to what are these pins connected?
That the initialization order changes the behavior gives one thought of that during McSPI initialization, a device being communicated with is taking control of those pins and so if the GPIO is configured second, the issue is not seen.
Another element that is a bit interesting here is how the pins are tightly grouped together - do you have any other signals being used in the area like B13-B15? Any of them showing any unusual behavior at the time? Could be a valuable data point if so.
Best Regards,
Ralph Jacobi