cancel
Showing results for 
Search instead for 
Did you mean: 

NOR Write problem (hanging in busy state)

Selso LIBERADO
Associate III
Posted on February 05, 2018 at 19:47

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 ?

#nor
1 REPLY 1
Posted on February 05, 2018 at 20:25

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)

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..