Generating STM32 Registers From Array-Registers Only Works With Stride Of 4 Bytes

[tim-hilt]

[Please suggest a better title. It feels very convoluted]

Problem Description

The file all.zig contains register-definitions for almost all STM32 microcontrollers. It's generated from data hosted by the embassy project.

The data-format that acts as the source for the code-generator models multiple instances of the same registers (e.g. multiple channels of a DMA peripheral) as arrays. These arrays are mostly arrays of registers of the same type (effectively []u32), but in some cases they are arrays of register-clusters (e.g. []{ u32, u32, u32, u32 }).

The current code-generator skips over all instances, where stride is != 4

https://github.com/ZigEmbeddedGroup/microzig/blob/cdc15df90035c2b8cc5b60bb8e67ce1a3371de16/port/stmicro/stm32/src/generate.zig#L319-L322

This leads to the omission of several registers, that the embassy-data models as arrays of clusters

Example:

https://github.com/embassy-rs/stm32-data-generated/blob/aee345990e1a14efd018877b52aff1d63e16bb7f/data/registers/bdma_v2.json#L46-L55

Without this, DMA is effectively not usable on my Microcontroller.

Suggested Fix

I see two ways of fixing this issue:

1. Implementing code-generation all stride values (changes to data-model required)
2. Rewriting the code-generator to use vendor-provided SVDs + regz (same approach as stm32-rs)

[taylorh140]

So for some work around stuff. you can change the types a bit. but they need to match the stride. for example i was working on bxcan drivers that use the CANx.TX and CANx.RX registers. Since the pointer to the origin is still valid you can use it. however you must check that the stride length in bytes is correct.

in my case the @import("microzig").chip.types.peripherals.can_bxcan.TX type is correctly sized at 16 bytes (4 words) so I can just go ahead and make the change myself.

const CAN_TX = @as(([*]volatile bxcan_t.TX), @ptrCast(&CAN.TX))[0..4];

and then use the CAN_TX[idx] that works for me.

if the stride is two short you can add a struct that pads the value but its less optimal. I think using meta programming you can make a function that copies the fields exactly and adds the necessary padding to get the same effect. This is a nice temporary work around since the working solution would only apply to the pointer transformation line.

[taylorh140]

so i think right now the handling of things is not quite right.

    // process each registry file from embassy data set:
    //  https://github.com/embassy-rs/stm32-data-generated/tree/main/data/registers
    //
    // These contain:
    // - blocks (think extern struct)
    //   -items
    //       x block[]     => "name": "REG", "array": { "len": 3, "stride": 16 }, "block": "BLOCKNAME"
    //       - normal      => "name": "REG", "byte_offset": 0,
    //       - fieldset    => "name": "REG", "byte_offset": 0, "fieldset": "FIELDSETNAME"
    //       - fieldset[]  => "name": "REG", "array": { "len": 2, "stride": 4 }, "byte_offset": 32, "fieldset": "FIELDSETNAME" 
    //     - fieldsets (think packed struct / bit fields)
    //       - bitfield    => "name": "FIELD", "bit_offset": 0, "bit_size": 4, "enum": "ENUMNAME"
    //       - discontinuous fields => (not supported; split into multiple continuous fields)
    // - enums
    //   - name/bit size/description => "enum/ENUMNAME": { "values": [ { "name": "VAL1", "value": 0 }, ... ] }

I beleive we handle fieldsets of size 4 which makes sense.. but we do not handle block sets inside a block.

[tim-hilt]

@taylorh140 I saw the new feature of supporting uneven stride-sizes in 0.14.0. Is there something for me to test? I saw, that the commit at tag 0.14.0 still contains the big, fat all.zig file, which doesn't let me use DMA on an STM32L011K4, because of a big block of reserved []u8.

[taylorh140]

I haven't looked into it. but that sounds somewhat promising.