Strange behavior when trying to implement shared memory through DMA

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi folks,

I'm working on a project to use a PSoC 5 MCU to add extension capabilities to a vintage pocket computer. The pocket computer uses an LH5801 CPU running at 1.3MHz.

I've set up GPIOs to read the 16 bit address bus, read and write the 8 bit data bus, and read the R/W pin. CS for the MCU is by matching 1000 from the upper four bits of address. I have also set up indexed DMA to handle data writes to the MCU memory. Basically, a status register uses some bits from the upper address to get a page offset within a 4K buffer array in MCU memory (4K starting at 0x20002000), and the lower address 8 bits provide the rest of the indexing into the buffer. I grab the buffer address when CS goes high, then read in data when R/W goes low while CS is high.

This mostly works. The problem I'm having is that I can write into MCU memory, with the correct offset into the buffer, and read the data back out, as long as the data value being written doesn't start with 1000. If the data value does start with 1000, it seems like the low pulse on the R/W line is never caught.

This is a bit bizarre for a few reasons:

1. 1000 just happens to be the CS trigger. Coincidence?

2. I have tried implementations without DMA and had exactly the same problem.

3. When I have tried implementations that wrote to a single address in memory, instead of a range of addresses, I had no problem with 1000 values (e.g. 129 or 143).

I'm really pretty stumped now. I would have thought switching to a completely different way of doing things would at least have resulted in different problems.

Any ideas what might be happening or how to further troubleshoot this?


Thanks,
Paul

0 Likes
1 Solution
Anonymous
Not applicable

OK. So, to be clear, the correct answer is that DMA takes long enough to set up that it is nowhere near as fast to transfer a single byte as a CPU-driven for loop. A for loop with PSoC 4 wasn't fast enough for what I wanted to do, but the same one on PSoC 5 with a status register for page decoding, is fast enough to reliably emulate SRAM for a 1.3Mhz 8-bit processor.

View solution in original post

0 Likes
12 Replies