[chbot] Volatile struct puzzle

Sat Feb 5 20:43:52 GMT 2022

There are a few important points missing here:
1) Which STM32 processor? They are not all just "STM32" processors. They
range from the very simple Cortex M0 and M0+, through the M3, M4 and M33 up
to the M7.
Different cores have different caching behaviour. The M0 and M0+ have zero
caching and the M7 has extensive caching. If you're having a caching issue
then I suppose it is more likely to be an M7. Can you confirm that?
2) What compilation options are you using?
3) Volatile has pretty much nothing to do with caching. All volatile does
is ensuring that a registered value is not used and a memory access is
forced. It also ensures that the order of volatile accesses is maintained
(from a CPU perspective, not a cache perspective). It does nothing to
ensure cache coherency. For that you need to do what Paul says: uses memory
barriers.

Assuming you're using an M7, this is not your granny's microcontroller. It
does not perform memory accesses in order. It is superscaler (ie. it can
execute multiple instructions in parallel and does not execute them in
order), has a sophisticated branch predictor and, most importantly here -
it has a large cache. Thus you need to be careful to get your various
accesses in order.

https://www.sciencedirect.com/topics/engineering/m7-processor
http://ww1.microchip.com/downloads/en/DeviceDoc/Managing-Cache-Coherency-on-Cortex-M7-Based-MCUs-DS90003195A.pdf
https://www.sciencedirect.com/topics/engineering/memory-barrier-instruction

The Microchip doc gives some good explanations. It doesn't really matter if
it is an ST - what matters is that the core is the same.

You might find the cache controll functions and data barrier instructions
are helpful.
SCB_CleanDCache_by_Addr (uint32_t *addr, int32_t dsize)
__DSB()
etc

Regards

Charles

On Sun, Feb 6, 2022 at 1:12 AM Paul Davey <plmdvy at gmail.com> wrote:

> Have you tried sprinkling memory barriers between the CPU access to
> the DMA memory and the DMA operation trigger?
>
> On Sat, Feb 5, 2022 at 8:23 PM Andrew Dachs <dachsa492 at gmail.com> wrote:
> >
> > I see. Could it be that the initialisation code changes are just moving
> things about in memory rather than root cause? Why is it important that the
> control struct is volatile or is it really just the contents of DataBuffer
> that’s being changed?
> >
> >
> >
> > Sent from my iPhone
> >
> > On 5/02/2022, at 7:17 PM, Robin Gilks <gb7ipd at gmail.com> wrote:
> >
> > 
> > It is outside .data and explicitly NOT initialised.
> > Excerpts from the linker file...
> >
> > /* Specify the memory areas */
> > MEMORY
> > {
> > DTCM (xrw) : ORIGIN = 0x20000000, LENGTH = 128k
> > RAM (xrw) : ORIGIN = 0x20020000, LENGTH = 368K
> > BOOTRAM (xrw) : ORIGIN = 0x2007C000, LENGTH = 16K
> > FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 2048K
> > }
> >
> > /* used by audio buffers and JPEG h/w */
> > .MCU_Data_section 0x20000000 (NOLOAD) : { *(.MCU_Data_section) } >DTCM
> >
> > The DTCM memory is by default available to all internal DMA buses (so
> saves playing with the cache setup using 'HAL_MPU_ConfigRegion()'.
> >
> >
> > On Sat, Feb 5, 2022 at 6:47 PM Andrew Dachs <dachsa492 at gmail.com> wrote:
> >>
> >> Hi Robin,
> >> Is your special area of memory inside .data and part of the
> initialisation on startup?
> >> Andy
> >>
> >>
> >>
> >> Sent from my iPhone
> >>
> >> On 5/02/2022, at 5:42 PM, Robin Gilks <gb7ipd at gmail.com> wrote:
> >>
> >> 
> >> Hmmm - thanks Mark, I  hadn't thought of packing issues.
> >> It's not like I'm trying a union to another struct so positioning would
> be critical. That being the case I think I'll keep that thought on the back
> burner for now..
> >>
> >> Cheers
> >>
> >>
> >> On Sat, Feb 5, 2022 at 4:10 PM Mark Atherton <markaren1 at xtra.co.nz>
> wrote:
> >>>
> >>> I have seen issues with data segments, where large chunks (u32, u8*)
> >>> follow small chunks (u8).
> >>>
> >>> Try changing
> >>>
> >>>  > uint8_t State;
> >>>  > uint8_t *DataBuffer;
> >>>  > uint32_t DataBufferSize;
> >>>
> >>> to
> >>>
> >>>  > uint32_t DataBufferSize;
> >>>  > uint8_t *DataBuffer;
> >>>  > uint8_t State;
> >>>
> >>> -Mark
> >>>
> >>>
> >>>
> >>>
> >>> On 5/02/2022 1:50 PM, Robin Gilks wrote:
> >>> > Some may recall that a year or 2 ago I had great problems getting the
> >>> > hardware JPEG encode to work on an STM32 processor. It turned out
> that
> >>> > the memory cache attributes manifested as a race condition between
> DMA
> >>> > and CPU access.
> >>> > The problem has just reappeared as a result of updating
> >>> > from arm-none-eabi-gcc-9.2.1-1.1 to arm-none-eabi-gcc-10.3.1-2.3.
> >>> >
> >>> > After a few pokes at the code I've narrowed the issue down to
> whether a
> >>> > volatile struct element is initialized statically  or at run time.
> >>> > Interestingly the issue is inverted between compiler versions
> >>> > The buffer referenced by the structure element 'DataBuffer'  is
> defined
> >>> > and instantiated in a reserved section of memory that has the correct
> >>> > cache attributes
> >>> >
> >>> > typedef struct
> >>> > {
> >>> > uint8_t State;
> >>> > uint8_t *DataBuffer;
> >>> > uint32_t DataBufferSize;
> >>> > }JPEG_Data_BufferTypeDef;
> >>> > uint8_t
> >>> >
> JPEG_Data_InBuffer[CHUNK_SIZE_IN]__attribute__((section(".MCU_Data_section")));
> >>> > original code - works with gcc-9; fails with gcc-10:
> >>> > volatile JPEG_Data_BufferTypeDef Jpeg_IN_BufferTab =
> {JPEG_BUFFER_EMPTY,
> >>> > JPEG_Data_InBuffer, 0};
> >>> > current code fails with gcc-9 works with gcc-10:
> >>> > volatileJPEG_Data_BufferTypeDefJpeg_IN_BufferTab= {0, 0, 0};
> >>> > ...
> >>> > Jpeg_IN_BufferTab.DataBufferSize = 0;
> >>> > Jpeg_IN_BufferTab.State = JPEG_BUFFER_EMPTY;
> >>> > Jpeg_IN_BufferTab.DataBuffer = JPEG_Data_InBuffer;
> >>> >
> >>> > Note that NO other changes (apart from the compiler version) were
> made!!
> >>> > I'm at a total loss as to what is going on, hopefully someone can
> shine
> >>> > a light ;)
> >>> >
> >>> > --
> >>> > Robin Gilks
> >>> >
> >>> >
> >>> > _______________________________________________
> >>> > Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> >>> > https://lists.ourshack.com/mailman/listinfo/chchrobotics
> >>> > Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> >>> > Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> >>> > When replying, please edit your Subject line to reflect new subjects.
> >>> >
> >>>
> >>>
> >>> _______________________________________________
> >>> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> >>> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> >>> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> >>> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> >>> When replying, please edit your Subject line to reflect new subjects.
> >>
> >> _______________________________________________
> >> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> >> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> >> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> >> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> >> When replying, please edit your Subject line to reflect new subjects.
> >>
> >> _______________________________________________
> >> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> >> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> >> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> >> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> >> When replying, please edit your Subject line to reflect new subjects.
> >
> > _______________________________________________
> > Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> > https://lists.ourshack.com/mailman/listinfo/chchrobotics
> > Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> > Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> > When replying, please edit your Subject line to reflect new subjects.
> >
> > _______________________________________________
> > Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> > https://lists.ourshack.com/mailman/listinfo/chchrobotics
> > Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> > Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> > When replying, please edit your Subject line to reflect new subjects.
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20220206/1f2afe76/attachment-0001.html>