Invalid bitband defs in F4 STLIB

[jpeacock2399]

Posted on May 16, 2013 at 19:28

I just spotted some invalid defs in the CMSIS stm32F4xx.h definitions file. In the section on bitband definitions it has entries for backup SRAM, SRAM2 and CCM SRAM:

#define CCMDATARAM_BB_BASE ((uint32_t)0x12000000) /*!< CCM(core coupled memory) data RAM(64 KB) base address in the bit-band region */ 
#define SRAM2_BB_BASE ((uint32_t)0x2201C000) /*!< SRAM2(16 KB) base address in the bit-band region */ 
#define BKPSRAM_BB_BASE ((uint32_t)0x42024000) /*!< Backup SRAM(4 KB) base address in the bit-band region */

The definitions for SRAM2 and BKPSRAM are wrong, and the one for CCM implies that CCM memory is bitband capable, when the ARM manual states only the two 1MB regions for regular SRAM and peripheral registers (which includes backup SRAM) are valid. A heads-up to anyone using bitband on an F4, don't use these definitions. The SRAM (or SRAM1) and PERIPH definitions work fine. Jack Peacock #bitbanding #bitbanding

[waclawek.jan]

Posted on May 21, 2013 at 10:35

And, according to the same key,

#define SRAM3_BASE            ((uint32_t)0x20020000) /*!< SRAM3(64 KB) base address in the alias region                              */ (for the 'F427/'F437) is invalid, too. JW

[Tesla DeLorean]

Posted on May 21, 2013 at 16:43

I'm not sure what the ''alias'' reference is about but

SRAM1 is situated 0x20000000..0x20001BFFF (112KB) SRAM2 is situated 0x2001C000..0x20001FFFF (16KB) SRAM3 is situated 0x20020000..0x2002FFFF (64KB) CCMRAM is situated 0x10000000..0x1000FFFF (64KB) Given the placement of SRAM2, it's pretty hard to see any valid cases where an F4 die has less than 128KB. SRAM3 is documented, and valid for parts with >256KB, what's the issue here?

[waclawek.jan]

Posted on May 21, 2013 at 17:26

PM0214, chapter 2.2.5 Bit-banding

bit_word_offset = (byte_offset x 32) + (bit_number x 4) e.g. for SRAM2: starts at 0x2001C000, i.e. byte offset is 0x1C000, and as the bit-band-alias area starts at 0x22000000, SRAM2's bit-band-alias starts at 0x22380000  (that's where SRAM2's lowest byte's lowest bit's alias is located). And, as John wrote above, CCM is not in the bit-band-able region. JW

[Tesla DeLorean]

Posted on May 21, 2013 at 17:55

I will concur that SRAM2_BB_BASE above is totally bogus, and that BB in CCM is not workable.

This is also bogus #define SRAM3_BB_BASE         ((uint32_t)0x22020000) /*!< SRAM3(64 KB) base address in the bit-band region                              */ I'd expect this to be 0x22400000, but haven't checked it for functionality. This however appears valid #define SRAM3_BASE            ((uint32_t)0x20020000) /*!< SRAM3(64 KB) base address in the alias region                              */

[waclawek.jan]

Posted on May 21, 2013 at 18:07

> This however appears valid

>

#define SRAM3_BASE            ((uint32_t)0x20020000) /*!< SRAM3(64 KB) base address in the alias region                              */

Oh, yes, you are absolutely right, of course; mea culpa and apologies. Copied the incorrect line from the header (perhaps in frustration that the score of errors:correct displays from the forum software today is around 2:1). JW

[Tesla DeLorean]

Posted on May 21, 2013 at 18:11

I'd expect this to be 0x22400000, but haven't checked it for functionality.

Confirm, this works as expected. The include file is a bit of a mess, hopefully this will get resolved in a subsequent release.

[jpeacock2399]

Posted on May 21, 2013 at 21:12

The Cortex M ARM manual shows a 1MB region mapped to bitband for SRAM, so it makes sense that SRAM3 works.  Looks like SRAM bitband aliases won't be a problem until internal SRAM exceeds the 1MB limit starting at 0x2000 0000.

CCM RAM doesn't work because it's outside the 1MB alias range for SRAM and peripherals.   Jack Peacock

[cem]

Posted on March 26, 2015 at 01:31I guess it should be 0x22380000 given SRAM1 is 112KB and and SRAM2 starts at 0x2001C000..