2018-02-05 10:47 AM
We're using STMCube to integrate two types of NOR Flash : MICRON and CYPRESS.
We are using the HAL_NOR_ProgramBuffer() function, memory data with = 16 bits.
Some tests showed that we could not write over the first one secotr (128k) beacuse of these lines :
NOR_WRITE(NOR_ADDR_SHIFT(deviceaddress, uwNORMemoryDataWidth, uwAddress), NOR_CMD_DATA_BUFFER_AND_PROG);
NOR_WRITE(NOR_ADDR_SHIFT(deviceaddress, uwNORMemoryDataWidth, uwAddress), (uwBufferSize - 1U));�?�?
A collegue resolved this problem modifying these two lines as following :
NOR_WRITE(NOR_ADDR_SHIFT(deviceaddress, uwNORMemoryDataWidth, uwAddress - deviceaddress), NOR_CMD_DATA_BUFFER_AND_PROG);
NOR_WRITE(NOR_ADDR_SHIFT(deviceaddress, uwNORMemoryDataWidth, uwAddress - deviceaddress), (uwBufferSize - 1U));�?�?
We manage to write the whole NOR memory now with the MICRON Chip, whereas the Cypress hangs at the mid of à block size.
Still we don't understant the NOR_***_SHIFT marco :
#define NOR_ADDR_SHIFT(__NOR_ADDRESS__, NOR_MEMORY_WIDTH, ADDRESS) (uint32_t)(((NOR_MEMORY_WIDTH) == NOR_MEMORY_16B)? ((uint32_t)((__NOR_ADDRESS__) + (2U * (ADDRESS)))):\
((uint32_t)((__NOR_ADDRESS__) + (ADDRESS))))�?�?
Why do we multiply the address when using 16 bits mode ?
Shall we pass the address in word count ?
#nor2018-02-05 11:25 AM
Because when writing ma gic addresses to the NOR device to unlock/send commands the address bus output by the STM32 shifts right one bit for 16-bit mode. Note the address space in the STM32 is byte wide, and bit A1 internally reflects as A0 externally and byte addressing is managed via Byte Lanes.
ie 0x2AAA -> 0x60000000 + (0x2AAA << 1)