- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
Solved! Go to Solution.
- Labels:
-
PSoC5 LP MCU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
"Engineering is an Art. The Art of Compromise."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the info Len.