I'm wondering if there is some tribal knowledge related to getting a BMP working with a Cortex M1 softcore? I'm tinkering with this now on a Gowin GW5AST and running into some issues. Seems like it should be possible but want to loosely inquire first.
Cortex M1 support #2190
Without an explanation of what those issues are, what you've tried, what logs from BMD say, and such - it's very hard to begin to know what to suggest or what could possibly be wrong. Please share details and information enough to understand what is failing and we'll do what we can to point you in a suitable direction
Sure, the initial question was more of a first pass to see if it's even been done before. For more context though, I have a BMP23 wired up to a Gowin GW5AST FPGA with pins constrained for clock and data, wired up to the cortex M1 softcore I have instantiated, and have made a few attempts at invoking mon swd with some symptoms of life but not success quite yet:
(gdb) mon swd
Target voltage: 3.3V
SWD scan failed!
Failed
with the debug port outputting:
Switching from dormant to SWD
DP DPIDR 0x2ba01477 (v1 rev2) designer 0x43b partno 0xba
AP 0: IDR=44770001 CFG=00000000 BASE=e00ff000 CSW=a3800040 (AHB3-AP var0 rev4)
Halt via DHCSR(01030003): success after 3ms
ROM Table: BASE=0xe00ff000 SYSMEM=1, Manufacturer 43b Partno 470 (PIDR = 0x04002bb470)
0 0x0e000e000: 0x00000000 <- does not match preamble (0xb105000d)
1 0x0e0001000: 0x00000000 <- does not match preamble (0xb105000d)
2 0x0e0002000: 0x00000000 <- does not match preamble (0xb105000d)
ROM Table: END
This sort of smells like the Cortex M1 isn't presenting the correct information. Currently digging
Oki, that looks like a great start in that SWD comms are working - so yes, you probably want to validate your CoreSight components are instantiated correctly and have their identification registers and that those registers are set to the proper values. What you're aiming to see is a SCS (System Control Space) entry along with ones for things like the FPB, DWT, and any other debug blocks that might be present (ETMs, ITMs, etc). When BMD sees the SCS it'll identify a Cortex-M core and what kind. You will want to provide some way to tell that this is your device specifically, not just some generic Cortex-M core - but you can do this as a register you can read from the debug interface, you don't necessarily have to futz with the ROM tables or anything similar to get there.
alright after some trial/error I'm seeing success being able to load a program at least:
(gdb) mon swd
Target voltage: 3.3V
Please report unknown device with Designer 0x43b Part ID 0x470
Available Targets:
No. Att Driver
*** 1 Unknown ARM Cortex-M Designer 0x43b Part ID 0x470 M1
(gdb) att 1
Attaching to program: /home/akiel/GMD_workspace/softcore_fw_example/Debug/softcore_fw_example.elf, Remote target
⚠️ warning: while parsing target memory map (at line 1): Required element <memory> is missing
delay_ms (nms=100) at ../USER/delay.c:87
87 temp = SysTick->CTRL;
(gdb) load
Loading section .text, size 0x1d0c lma 0x0
Loading section .ARM.extab, size 0x30 lma 0x1d0c
Loading section .ARM.exidx, size 0xa0 lma 0x1d3c
Loading section .data, size 0x158 lma 0x1ddc
Start address 0x0000051c, load size 7988
Transfer rate: 102 KB/sec, 726 bytes/write.
(gdb) c
Continuing.
I forced alot of this by commenting out the checks for the proper preambles. let me make sense of my changes and may have a PR. will update here
I have a very dirty hack here to get something working on my end. I think it's worth experimenting with other implementations of the M1 soft core on other FPGA's to create a better solution that's more diverse but as I understand it the part number , cont code, and ID code are going to be the same across all M1 implementations
https://github.com/akielaries/blackmagic/pull/1/changes
I will stew on this for a bit before making a PR. I am curious of your thoughts nevertheless. I doubt many are using an M1 cortex these days but it's one of the few Gowin soft cores offered through their tools
Our immediate thoughts are that:
0x2ba01477Uis an entirely generic ARM ID code and is seen on quite a large number of different devices supported by BMD as this encodes a DPv1 interface that's using a 4-bit IR - for example, this shows up on the Tiva-C JTAG interface, and the LPC43xx debug interface.- We would far rather you fixed the PIDR and CIDR registers to read out correctly for your core, than change the logic in BMD for how to find CoreSight parts as the checks that are present are there to prevent misdiscoveries.
- The Cortex-M layer changes all look good though, save for no need to set the
target->driverin the probe switch-case.. this would be where you'd add a probe routine for your part instead and include in its address space some way to uniquely identify your thing to allow BMD to check and lock in that it's your part and to use the target-specific support you engineer for it.
yeah seems the preamble for the component IDs are just not being read. weird. will continue to dig and circle back
when running the BMP firmware built that forces success and doesn't care about the CIDR and PIDR values, i'm able to probe ROM directly it seems and see a valid preamble here for each of the component ID:
(gdb) x/wx 0xE00FFFF0
0xe00ffff0: 0x0000000d
(gdb) x/wx 0xE00FFFF4
0xe00ffff4: 0x00000010
(gdb) x/wx 0xE00FFFF8
0xe00ffff8: 0x00000005
(gdb) x/wx 0xE00FFFFC
0xe00ffffc: 0x000000b1
== 0xb105100d
edit: semi valid it seems. hmmm
Gowin Semiconductor got back to me and relayed:
Cortex-M1 is NOT a standard CoreSight system. Even though it implements ADIv5, a lot of the auto-discovery assumptions break down.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?