Need system timer register definitions for ARM

[Infinoid]

The atsamd51 includes a general system timer, but the register definitions for this system timer are missing from the generated files in src/device/sam/. The register definitions are present for atsaml11, and none of the other atsam* devices.

Here is an example program which defines the registers manually, sets the timer up to trigger an interrupt every 10ms, and implements an interrupt handler that blinks the LED. It runs on the feather m4 express, and should also run on the itsybitsy-m4.

https://gist.github.com/Infinoid/ea2002fbf6989f8dbaff57a63ccda2ba

It runs and blinks the LED, so the hardware is present in this chip. It would be great to be able to use this hardware without having to lug around the register definitions myself.

[Infinoid]

It's actually kind-of hard to find documentation on this timer. The SAM D5x/E5x Family Data Sheet just says: Refer to the Cortex-M4 Technical Reference Manual for details.

The Cortex-M4 Technical Reference Manual says: Registers not described here are described in the ARM® v7-M Architecture Reference Manual.

The ARM® v7-M Architecture Reference Manual does define the system timer, in section B3.3. and asserts that this hardware must be present in all ARMv7-M cores.

[deadprogram]

The registers are not in the SVD files for those devices. Probably they should not be in the atsaml11 SVD file either I suspect that was an error on the part of the creators of that one.

Actually, that code likely belongs in https://github.com/tinygo-org/tinygo/blob/master/src/device/arm/arm.go since it applies to all of the various ARM based processors.

As you may notice, the arm.go file is not generated. device wrappers cannot be generated by TinyGo unless it is in the SVD files, which are maintained here https://github.com/posborne/cmsis-svd and are based on vendor-provided files.

I would suggest a PR to add to the arm.go file, probably.

[Infinoid]

It looks like the recent v0.9.0 release added definitions for atsamd51 and atsamv71. These weren't present in v0.8.0, sorry for reporting outdated info. The current platforms that have SysTick register definitions are:

• atsamd51
• atsamv71
• atsaml11

(Based on a search for RVR_RELOAD.)

The generated definitions for atsaml11 look wrong, too. RVR_RELOAD is not a single-bit field at position 0x18; it is an integer field at position 0, 0x18 bits wide. Same story with CVR_CURRENT; it's not a single bit at offset 0x18, it's a 0x18 bit wide integer field at offset 0.

[Infinoid]

I would suggest a PR to add to the arm.go file, probably.

As for putting it in arm.go, I am not sure the exact same timer feature is present in the same form and the same location on all ARM chips. But I suspect it's present on a much larger set of targets, and the register set is unlikely to vary much. I can cook up a PR that covers the common subset, then we can see how well it works in practice.

One example of a missing target is atsamd21. The system timer feature should be present based on the datasheet, but the register definitions aren't there.

I scanned through the reference manuals and I do see some minor differences between ARMv6-M, ARMv7-M, and ARMv8-M:

• On ARMv7-M, the feature is apparently mandatory.

• On ARMv6-M, and Cortex-M0 by extension, the SysTick is optional / product-specific. But when present, the register definitions look identical to ARMv8-M.

• On ARMv8-M, and Cortex-M23 by extension, the presence of SysTick is optional / product-specific. In some cases there may be have 2 of them, for each separate security domain. But the primary one is at the same memory location, so a common driver might just ignore the second one.

• On ARMv8-M and ARMv6-M, the counter and reload registers are both 24 bits wide. On ARMv7-M, the counter register is 32 bits wide; the reload register is still 24 bits. So it can be used in single-shot mode for longer time periods, but the periodic timer functionality is the same.

[deadprogram]

@Infinoid this research you are doing is really great!

[deadprogram]

654 has been merged, so now closing this issue. Thanks!