We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi guys, I am interested in exploring a scenario when Cortex M4 cpu performs a 16-bit static memory read when 32-bit memory is actually on the board.
The 16-bit memory chip is connected to lower half of the data bus, signals D0..D15 and there are two cycles required to read full 32-bit DWORD.
What actually happens to the D16..D31 data lines on the cpu during such 16-bit read cycles?
Are they left in high-impedance mode? Are they driven?
I would like to make my custom board with two variants: one with a single 16-bit flash memory and other with dual flash memory (two 16-bit chips in parallel).
Both flash chips share address bus, CE, OE, WE signals, they just handle lower or upper 16-bits of the 32-bit data bus, respectively.
If the CPU is handling 16-bit read transactions, the other flash chip connected to the upper half data bus will see the CE and OE and will try to drive the D16..D31.
And I wonder about the compatibility of the CPU configured for 16-bit mode on a board with both flash chips populated.
Will the CPU play nicely keeping D16..D31 in high impedance mode during 16-bit cycles or will it drive these pins somehow causing collisions?
It depends on the chip design, more particularly, the external memory interface part.
At the processor level (inside the chip), the data lane used in the on-chip bus (AHB) access depends on the size of the access and the address value. This is illustrated in here. If the on-chip bus transfer is 16-bit, half of the data bus lanes are unused:
* for read operations, the read data appear on the unused bus lanes is ignored by the processor.
* for write operations, the memory interface block will ignore the data on the unused bus lanes.
For your application, depending on the chip and PCB design (e.g. if there is any pull up at the PCB level or at the IO pin level), the upper 16-bit of the data could be pulled high (0xFFFF), this value would be ignored by the processor on a 16-bit read.
If the software perform a 32-bit read, you will get 0xFFFFabcd, where abcd is the data you want and the 0xFFFF in the upper 16-bit need to be masked off by software.
If you want to read 32-bit of data from the flash, you might end up need to read 16-bit from address N, and 16-bit from address N+4. And then use software to merge them together. This is okay for data access, but performance would be slower as there is software overhead to merge the data. This arrangement is not suitable for executing code from 16-bit flash.
If the external flash is for software execution, some microcontrollers might have programmable 32-bit external memory interface and you can program specific address range to be 16-bit memory. In such configuration, a 32-bit access is automatically converted to two 16-bit accesses by the memory interface (no need for software overhead, and software execution from 16-bit flash is supported).
In summary, you need to check the manual of the microcontroller you are planning to use to see if its memory interface support such configuration. Since this is not part of the processor design, we cannot provide you detail of how this would be handled.
regards,
Joseph
I observe bus conflict on my PCB using LPC4088 cpu by NXP.
Processor is for some reason driving L on D16-D31 during 16-bit read cycles to Flash memory.
Very unexpected: I see about 1V on D31 instead of full 3.3V driven by blank flash memory.
I have no pull-up resistors on the data lines.
I'm afraid you need to ask NXP support, or post the question on NXP community (https://community.nxp.com/community/lpc) to see if they can provide you with an answer. (The memory interface part is not a part of the Cortex-M4). Please also double check the configuration code for the memory interface to see if there is any programmable options to force the upper 16-bit to tristate.