"Counter + UDB" component uses unaligned registers

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ricardoquesada
Level 4
Level 4
First solution authored 50 sign-ins 25 replies posted

Hi,

I'm using the "Counter" component using the UDB implementation (since I need 32-bit resolution).

I noticed that if I enable the "Trap if unaligned", then whenever I try to read the Counter value it faults with "unaligned access".

I'm enabling the traps by doing:

 

```

void myfunc()

{

// As defined in Cortex M3 Technical Reference Manual

#define  CY_NVIC_CCR_UNALIGN_TRAP = BIT(3)

   *CY_NVIC_CFG_CTRL_PTR |= CY_NVIC_CCR_UNALIGN_TRAP;

   // Here it crashes.

   Counter_ReadCounter();

}

```

To be more specific, "Counter_ReadCounter()" calls:

    return (CY_GET_REG32(Counter_STATICCOUNT_LSB_PTR));

And "Counter_STATICCOUNT_LSB_PTR" is defined as 0x4000644a which is not 4-byte aligned.

 

So, is there a way to tell UDB-based components to only used aligned registers?

Thanks!

0 Likes
1 Solution

ricardo,

Thank you for letting me understand your reasoning.

Sadly I have "bad" news for you.  (Not bad and a bad way.)

The PHUB data width from the CPU (32-bit) to the UDB registers (16-bit) mean that even if you use the DWR/Directives to longword-align the registers it will not benefit you.  If longword-aligned, it will still take two BUS clock cycles to read the counter value.

I recently used the UDB editor to create my own minimally featured 32-bit counter for the EXACT same reasons you are trying to achieve.  With this custom counter, the counter register was forced to long-word aligned.   However, whether accessed by CPU (or by DMA in my case), two BUS clock cycle fetches were used to get the 32-bit data instead of the preferred one cycle.   It took me many days and quite a bit of datasheet and app note research to reveal this understanding.

In general, a DMA move to RAM is more efficient in CPU cycles but depending on your Application and your use of the data it may be a moot point.

Len
"Engineering is an Art. The Art of Compromise."

View solution in original post

0 Likes
4 Replies
Len_CONSULTRON
Level 9
Level 9
Beta tester 500 solutions authored 1000 replies posted

ricardo,

You are correct.   It doesn't force a longword alignment.   However it is my understanding that the ARM will tolerate this word-alignment and correctly work.   Is there reason that you need longword-alignment?

You can use the DWR/Directives to force UDB alignment.  It's tricky and a bit confusing but it should work.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Thanks Len.

Yes, "Counter" works Ok with unaligned access.

Ideally, I'd like to have only aligned code, since it is faster [1]. So, as recommended by ARM, I have the "trap if unaligned" to catch possibles unaligned code and fix it.

IIUC, you suggest that I implement "Counter" myself using UDB, and by using "DWR" I can force alignment. Is that correct? (Just double-checking since I haven't used UDB directly before).

 

Thanks!

 

[1]: https://developer.arm.com/documentation/dui0552/a/the-cortex-m3-instruction-set/about-the-instructio...

0 Likes

ricardo,

Thank you for letting me understand your reasoning.

Sadly I have "bad" news for you.  (Not bad and a bad way.)

The PHUB data width from the CPU (32-bit) to the UDB registers (16-bit) mean that even if you use the DWR/Directives to longword-align the registers it will not benefit you.  If longword-aligned, it will still take two BUS clock cycles to read the counter value.

I recently used the UDB editor to create my own minimally featured 32-bit counter for the EXACT same reasons you are trying to achieve.  With this custom counter, the counter register was forced to long-word aligned.   However, whether accessed by CPU (or by DMA in my case), two BUS clock cycle fetches were used to get the 32-bit data instead of the preferred one cycle.   It took me many days and quite a bit of datasheet and app note research to reveal this understanding.

In general, a DMA move to RAM is more efficient in CPU cycles but depending on your Application and your use of the data it may be a moot point.

Len
"Engineering is an Art. The Art of Compromise."
0 Likes

Thanks for the info Len.

0 Likes