2019-08-17 06:23 AM
I'm testing STM32MP157A for our new projects. The MPU VCC is 1V8, USB is 3V3. Debugger is connected to two SWD pins. One of first test is:
S_GPIO_ALT(GPIOA,13,2);
S_GPIO_ALT(GPIOA,14,2);
RCC->MCO1CFGR = 0x10f0;
RCC->MCO2CFGR = 0x10f0;
for (;;);
So far so good, code is started, I can see 4 and 25MHz at PA13/14.
in openocd I did:
> bp 0x2ffc25e0 4 hw
breakpoint set at 0x2ffc25e0
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
stm32mp15x.cpu0: MPIDR level2 0, cluster 0, core 0, multi core, no SMT
target halted in ARM state due to breakpoint, current mode: Supervisor
cpsr: 0x400001d3 pc: 0x2ffc25e0
MMU: disabled, D-Cache: disabled, I-Cache: disabled
It seems ok. I tested AXI access, confirmed that I'm in TZ secure state, can read even ROM firmware.
Openocd polls MP1 every 100ms by 2 SWD register reads (blue), MCOs are stable (yellow):
Ok, I reset, reupluad code, all the same way, but now, no breakpoint, let's use halt:
> halt
stm32mp15x.cpu0 rev 5, partnum c07, arch f, variant 0, implementor 41
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x400001d3 pc: 0x2ffc25e0
MMU: disabled, D-Cache: disabled, I-Cache: disabled
It seems the same as before (it should). But wait, what is this:
MCO outputs are no longer there, when MPU is in halt ! Even more interesting is,
outputs are on every 100ms - each SWD register read turns GPIOs back on for a while but then they are off again.
What I tested:
It seems as if there is another asynchronous signal in the SoC which can manipulate GPIOs
and SWD somehow affects it.
The behavior is strange and we'd like to find what causes it, before we decide on this SoC.
Thanks, Martin
2019-09-03 04:46 AM
Hello Martin,
we could not reproduce the issue with ST deliverable and we are suspecting issue with openocd version you are using.
Openocd version (and patches) compatible with ST delivery can be found here: https://github.com/STMicroelectronics/meta-st-stm32mp/tree/thud/recipes-devtools/openocd
This is Yocto recipe but you can easily find the version reference and the 5 patches to apply on it. This will add also the support of ST link that is the easiest simple way to debug on ST ref boards.
The official OpenOCD does not support (yet) STM32MP1 nor the ST-Link extension for Cortex-A
To allow us to replicate this use case, would you please share:
2019-09-05 11:05 AM
Hello Bernard,
thanks for the reply. I was waiting for DK2 board to arrive so that I can retest it on it. I've done it just now, but the "bug" is somehow gone now...
I'm not sure, but I probably updated Openocd in meantime (I regularly compile from GIT tree because I often add new drivers/patches).
Just now it works with both of my adapter (FTDI based in-house one) and with stlink-dap.
I'll return if I can manage to trigger it.
Just now I have to make LPDDR2 work. BTW, can I take oportunity and ask why LPDDR2 is in RM marker as unsupported in 0.8 pitch packages ?
It is weird ...
Martin
2019-09-08 11:26 PM
For system point of view, it does not make sense to put LPDDR2/3 which are only available on pitch 0.5mm or below with STM32MP1 using pitch 0.8mm which target lower cost PCB.
Anyway, there is no blocking mechanism using LPDDR2/3 with 0.8mm packages, but signal integrity analysis was not done with LPDDR2/3 on these packages, and they are not supported by CubeMX nor supported by layout examples.
2019-09-09 03:01 AM
Hello Patrick,
thanks for the reply. I'm glad to hear there is no technical obstacle except SI. Well it still makes sense (AFAIK) because LPDDR2 is 0.65 ball pitch
and has strategic spaces to allow routing without via between balls (can be done on 4mil, 4layer no VIP). However 0.5mm pitch MP1 can't
be done without VIP, can be ?
The main reason is consumption in mobile device. DDR3L AC/ODT termination is power hungry. We can try to go without terminations
or use serial terms but we need to measure overshots then to be on safe side.
BTW, ref. manual talks about DCU unit in PUBL, it is in u-boot headers too but no register description. I found some clues from Synopsys pdf, but IP parameters are missing (as command cache size e.g.). Is it planned to document it ? It is nice interface to debug DDR SI..