search

blackmagic-debug / blackmagic

In application debugger for ARM Cortex microcontrollers.
GNU General Public License v3.0
3.29k stars 774 forks source link

Cortex-M33? #479

Closed nickray closed 3 years ago

nickray commented 5 years ago

Hi, is anyone working on or planning to work on Cortex-M33 support? Given it's Cortex-M4 + extras, maybe the necessary adjustments aren't huge. There's for instance a nice "LPC55S69-EVK: LPCXpresso55S69" dev board available.

UweBonnes commented 5 years ago

When STM32L5 is available, I will sure have a look. What about trying yourself? Compare flash algo of the LPC55S69 with already implemented algos for LPC. But wait, doesn't have the LPC IAP calls for programming? Are they the same? Then a lot of the work is already done.

Furthermore I guess that LPC55S69 has the newer ADIv5 interface where you can read out the MCUID from the AP. No need for the IAP call when probing. This probing is ugly when done on other CPUs...

What BMP capable hardware do you have? With an STlinkV2, you can try https://github.com/UweBonnes/blackmagic/tree/stlinkv2. As with the libftdi adapters, BMP runs on the PC and has much better debug output capabilities and no need for BMP firmware upload. That makes debugging easier. When done, program your "real" BMP.

nickray commented 5 years ago

Cool, good to know, particularly about your PC branch! Who knows when the L5 will actually be out, the NXP is (a dual-core monster...) available today :)

Intent was definitely just to ask about status; re. implementing it myself will have to learn the chip (via on-board J-Link) a bit first.

UweBonnes commented 5 years ago

ST did not meat there promise of general availability of the L2 in Q2 2019...

UweBonnes commented 5 years ago

L2->L5

JJJollyjim commented 5 years ago

Also keen on using this with a Cortex M23 (also an armv8 target) :+1:

mayanez commented 4 years ago

Has there been any update on this? I'm also interested in this 😃

UweBonnes commented 4 years ago

With #507, the infrastructure to read the romtable is there. Probably targets/stm32l4 can be made to read and program the L5 with not to much effort. L5 is nit high on my agenda. Contributions welcome!

mean00 commented 4 years ago

In case it helps, this is the romtable dump of a STM32L552

Leaving MASS Mode Enter SWD Read Core ID: 0x0be12477 RESET_SEQ succeeded TARGETID 00000001 AP 0: IDR=14770015 CFG=00000000 BASE=e00fe003 CSW=0b800040 ROM: Table BASE=0xe00fe000 SYSMEM=0x1, PIDR 0x00000a0472 ROM: Table BASE=0xe00ff000 SYSMEM=0x1, PIDR 0x04000bb4c9 0 0xe000e000: Debug component - Cortex-M33 () (PIDR = 0x04000bbd21) 1 0xe0001000: Debug component - Cortex-M33 () (PIDR = 0x04000bbd21) 2 0xe0002000: Debug component - Cortex-M33 () (PIDR = 0x04000bbd21) 3 0xe0000000: Debug component - Cortex-M33 () (PIDR = 0x04000bbd21) 4 Entry 0xfff41002 -> Not present 5 0xe0041000: Debug component - Cortex-M33 () (PIDR = 0x04002bbd21) 6 0xe0042000: Debug component - Cortex-M33 () (PIDR = 0x04000bbd21) 7 Entry 0xfff44002 -> Not present ROM: Table END 1 0xe0040000: Debug component - Cortex-M33 () (PIDR = 0x04000bbd21) 2 Entry 0x1ff02002 -> Not present 3 Entry 0x1ff02002 -> Not present ROM: Table END

UweBonnes commented 4 years ago

Someone needs to write code to decode the CortexM33 romtable pidr/cidr bits!

themadinventor commented 4 years ago

I'm making some progress on this. The same PIDR is used for each of the SCS, DWT, FPB and ITM blocks:

CoreSight permits that two or more functionally different components are permitted to share the same Part number, so long as they have different values of the DDEVTYPE or DDEVARCH registers.

So the approach I've come up with is to, after finding PIDR 0x04000bbd21, checking the ARCHPART bits in DEVARCH. Those should be 0xA04 on a v8M SCS. If that's the case, just proceed with cortexm_probe.

This seems to work fine on the STM32L5. I haven't looked into the flash driver yet.

I'm personally more interested in the LPC55S69, but it's tricker to get working, due to the dual cores and debug authentication.

Anyway, I'll try to clean up my (simple) patch for generic v8M support and file a PR in the coming days :)

UweBonnes commented 4 years ago

Cortex-M33 is ADIv6 vs ADIv5 for M0... M7. The Decoding is different and best would be to implement that decoding. Perhaps a look at openocd and pyocd might give you some ideas.

UweBonnes commented 4 years ago

For the NUCLEO-L552, "pyocd gdb" dumps: 0001235:INFO:board:Target type is cortex_m 0001247:INFO:dap:DP IDR = 0x0be12477 (v2 MINDP rev0) 0001252:INFO:ap:AHB5-AP#0 IDR = 0x14770015 (AHB5-AP var1 rev1) 0001262:INFO:rom_table:AHB5-AP#0 Class 0x1 ROM table #0 @ 0xe00fe000 (designer=020 part=472) 0001265:INFO:rom_table:[0] 0001265:INFO:rom_table: AHB5-AP#0 Class 0x1 ROM table #1 @ 0xe00ff000 (designer=43b part=4c9) 0001269:INFO:rom_table: [0] 0001271:INFO:rom_table: [1] 0001273:INFO:rom_table: [2] 0001275:INFO:rom_table: [3] 0001277:INFO:rom_table: [5] 0001279:INFO:rom_table: [6] 0001281:INFO:rom_table:[1] 0001284:INFO:cortex_m_v8m:CPU core #0 is Cortex-M33 r0p2 0001290:INFO:cortex_m:FPU present: FPv5-SP 0001294:INFO:dwt:4 hardware watchpoints 0001301:INFO:fpb:8 hardware breakpoints, 1 literal comparators 0001320:INFO:server:Semihost server started on port 4444 (core 0) 0001320:INFO:gdbserver:GDB server started on port 3333 (core 0)

themadinventor commented 4 years ago

I took a look at how pyOCD handles it and updated the patch. I've filed PR #690 where we can discuss the solution :)

UweBonnes commented 4 years ago

Perhaps give a short reference to the sources you used in the patch description. Otherwise : Nice work! It adds however about 1 k to our flash, but I think that is worth it.

UweBonnes commented 4 years ago

https://github.com/UweBonnes/blackmagic/tree/stm32l5 adds L5 detecion, memory map and flash r/w. Option handling is missing.

themadinventor commented 4 years ago

Yeah, the pidr_pn_bits table is a beast. I'm thinking that lines that are aa_nosupport could be grouped together and wrapped with a #ifdef ENABLE_DEBUG, because they are of no use in a non-debug build anyway. That would save approx 400 bytes.

UweBonnes commented 4 years ago

Good idea!

UweBonnes commented 3 years ago

Cloes with #690

lucagessi commented 2 years ago

Hi. Is cortex-m33 actually supported? I read in cortexm.h header that there is some kind of reference to cortex-m33. I have a MGM210P0 module but blackmagic says that the chip in unknown during swd scan.

UweBonnes commented 2 years ago

CortexM2|33 is already recognized. Debug will work, as long as you do not use M2|33 specific registers. How to map secure and unsecure regions needs to be evaluated, as handling other M2|33 specific acpects.

MGM210P0 specific handling like memory map and flashing support needs to be done by somebody with the part in hand and some understanding of the specific implementation. Often new chips are a variant of already supported chips, so few additions may get you going.

Please run git head compiled for hosted as "blackmagic -t" and post the output of "blackmagic -t" as a new issue to request , or perhaps even as a start to implement MGM210P0 support.