Target interface analysis

Website security:

I have updated this website to default to TLS for connections.  I have a certificate supplied by my hosting provider.  I have also turned on member accounts.  I am hoping this will make it more convenient you, the readers to join the conversation.

Voltage level shifter:

I am still trying to decide the best way to go for adjusting to the target platform voltage.  SPI typically needs 3 bits output (SS, SCLK, MOSI) and one bit input(MISO)  Sometimes SPI needs more. JTAG needs 4 pins output(TCK, TMS, TDO, TRST) and one bit input(TDI). I found the JTAG signal description on this page. I2C needs two bits of bi-directional open drain signals.  I don’t know of any MicroControllers that can be programmed over I2C but there are flash memories that are programmed that way.

Based on this information, I can see that I would want 4 bits of output and 2 input along with a 2 bit open drain bi-directional.  This gives me a total of eight bits of data available to connect to the target device.  In addition to that, I need Target Vcc and GND and Vpp. Continue reading

Hantek MSO5202 Mixed Signal Oscilloscope review

mso5202d(Picture taken from Aliexpress.com)

Features:
This scope has 2 analog channels and 16 digital channels With Bandwidth up to 200 MHz.
1 Million sample points for the analog channels.
512K sample points for the Logic Analyzer channels
7 inch 800×400 color LCD display
USB Host for flash drives
USB client for PC control

Pros:
Capture 16 channels digital and 2 channels Analog simultaneously.
Export captured data to CSV file (useful for analysis)
Linux based (hackable!)
Familiar knob/face layout
Bright clear display

Cons:
No protocol analysis built in. No way to add protocol analysis.
No Linux PC support
Occasionally crashes
D0 is only digital trigger line

My experience with this scope:

The Purchase:
I bought the scope off of Aliexpress.com.  I knew I wanted at least 100MHz Bandwidth. I also didn’t have a lot to spend.   There wasn’t a big cost savings to go to the 100 MHz scope, so I decided to go ahead and get the 200 MHz Version.  Since I have bought the scope, I have seen information on how to hack the 60 or 70 MHz models to get the full 200 MHz performance. Assuming the scope lives up to their specs, I am happy to pay for the Higher bandwidth.  This scope is still a bargain with a price less than $500 US.  The seller shipped it to me for free with DHL shipping. The scope was delivered within 7 days.

Unboxing:
The scope came in the manufacturers box inside of another box it just fit inside.  I cut the tape on the outer box and opened it to see a handle on top of the manufacturers box.  I started to lift by that handle and the bottom of the manufacturers box fell out.  I had only lifted it a few inches so the bubble plastic protecting the scope protected it from damage.

First use:
I connected the power cord and nothing else. Turned on the power and it booted up quickly (less than 10 seconds). I then dug out the probes and hooked them up. The probes came with color rings to help identify which channel I was using.  Both probes came with red rings on both ends of the probe.  I looked at the scope and saw that the color for channel 1 is yellow and the color for channel 2 is blue.  I grabbed one of the probes and switched the colored rings to yellow and connected it to channel 1.  I repeated that process with blue rings for channel 2.  I connected the probes to the calibration tang on the front of the scope and did a quick adjustment of each probe.  The knobs have a good feel to them and the waveforms change the way I anticipated for each turn.  This made this scope feel very familiar.  All of this was done without reading the manual. So far so good!

Tinkering:
I have a circuit that the LCD got damaged on and I wanted to see how the Logic Analyzer worked.  The LCD is controlled by SPI. I hooked up the data lines, figured out how to trigger off of D0 and it kind of worked.  It wasn’t real clear how to get to the Logic Analyzer to begin with. I found it with playing.  Then I figured the chip select line of the LCD would be a good choice to trigger off of.  There is a short glitch just after power up that meant the scope triggered way too early.  I was disappointed that I couldn’t change the trigger to a different digital channel, I had to move the connections around instead. To make the connections to the LCD, I had to solder several 30 gauge wires to the data lines I was interested in. These wires are fragile so changing the connections to them was difficult.  The scoped locked up or did weird things while I was tinkering.

Data Capture:
I was also disappointed that there was no simple data analysis for the Logic Analyzer system.  I captured a chunk of the LCD SPI data and saved it as CSV file to a flash drive.  I put the flash drive into my computer and opened the CSV file with LibreOffice Calc.  With some complex cell calculations I was able to get Calc to show me the data that was sent for each time chip select was active. The good news is it showed me the circuit wasn’t damaged and a replacement LCD should fix the device.(The scope served it’s purpose)

Overall:
I found this scope to be very intuitive to use for analog signals.  The Logic Analyzer function is very useful but is not very intuitive and is missing some features.  If I had this when I was testing the SPI on the Uprogrammer board, I would have found my problems much quicker.  I watched a few of the hack videos on YouTube. They connect a USB to Serial bridge to the system and issue a few Linux commands. Linux is a great place to start hacking. On the back is a punch out with a Networking symbol next to it.  If it turns out that there is a chip that supports ethernet on the board, I would like to install the ethernet jack and see what happens.  From the hack videos, I can see there is a place on the PCB for the ethernet Jack.

My Opinion:
This an excellent scope for the price.  I have seen online videos that indicate problems when approaching the higher bandwidth limits of the scope.  I don’t believe these problems will affect me.  If you need high precision in near 200 MHz, I would suggest looking for a better scope.  Otherwise this will make a fine tool on your bench.  Firmware is still being developed for this scope, so I expect it to get better over time with updates. Since it is Linux based I also expect the community to hack it for better features than just a bandwidth upgrade.

Have you used one of these scopes?  Have you worked with one near 200 MHz?  What is your feelings about the lack of digital features? How about the occasional lock up?

Sigma Delta Testing V00I

Last Week I wrote to  and read from the SPI RAM but only verified it with a logic analyzer.  I read from the registers and sent them out on the serial line. Like before, I did a hello world test and actually expected to see hello world after the menu. It didn’t work, I forgot to take care of several things in the software. I adjusted the software a little at a time testing with each change until it started working.

Once I saw “Hello World” in my serial console, I decided to start testing the Sigma_Delta output.  I want to know if it causes system crashes without the voltage boost circuit having any connection to power. Without R5 or L2 installed, the boost circuit really can’t have much affect on the system. Q5 also isn’t installed so the Sigma Delta output on GPIO4 is driving to high impedance.

I changed the firmware so that GPIO4 is the Sigma Delta output.  Then I un-commented out the line in user_init() that configures and enables the Sigma Delta output.  Before, I had a very limited range of prescaler I could use for the Sigma Delta signal. I can set the sigma delta prescaler from 0 to 100.  I was expecting to get full range which would be 0 to 255.  So I went back into the software and looked to see if I made a math error.  The math is simple and it looks right so I decided to look at the Sigma Delta register definition.  The register definition matches the way the code is written.  I checked Kolban’s ESP8266 book, it didn’t have anything useful about the Sigma Delta.  I looked for it in Espressif’s  SDK programming guide and found nothing. Next I searched using Google. This turned up the page I had originally found on Espressif’s bbs.  It describes the prescaler being a value of 0 to 255. So I still don’t know why going bigger than 99 causes the system to crash.  It is not clear what is causing this rebooting.

I will look at the Sigma Delta software more next week. I have uploaded the current status of the code to GitHub.

I would love to hear from you readers.  The only comments I get are spam!

Switching to SPI from HSPI Firmware V00I

I decided to try to use the SPI module instead of overlap mode this week.  I went into the code that writes and reads from the SPI and changed the working registers to SPI in place of HSPI. I had to store and restore 6 variables in the writeRam() and readRam() functions.  It worked but sent more data than expected. I noticed that I left the overlap init code in place, I removed it and tried again. I still got more data than I expected. I searched for HSPI and found one place that I had forgot to change it to SPI. I fixed that and now it is working. The code is also working without crashing.

SPI Write Hello World

Next I added the read function back into the main code to see what would happen. I saw only 4 bytes on the SPI bus. I had missed a value change I needed to make the SPI read 12 bytes.    It seems that either the DMA or an Interrupt routine is taking control of the SPI Hardware before i can finish a read. I disabled interrupts and it’s still only sending the command (3) and the address (0) plus 6 more clock cycles.

Incomplete SPI Read

Since SPI is used for loading code into internal RAM as well as running it directly from flash, it might be difficult to figure out when I can use it for the SPI  RAM.  I had the HSPI appearing to work in overlap mode.  Since I can switch between overlap and normal mode on the fly, maybe the HSPI in overlap mode is the best choice. In the writeRam() and readRam() functions, I changed the all references to SPI Registers to HSPI Registers and I commented out the code to save and restore the SPI Registers.  I used find and replace to simplify the changes.  I searched on (SPI) and filled in the replace with (HSPI) and then I selectively hit REPLACE/FIND for each instance.

Then I built and tested the code, hopefully back to where I was last week.  I got all zeros but I hadn’t done a write since I started working on it this time. So I put the writeRam() just before the readRam() in user_init() and tried again. On the logic analyzer, the write looks exactly like I would expect. The read is still not getting anything but zeros for the data section.  Next step is to look at the HOLD and WP lines on the SPI RAM. I had to look at the datasheet to see what state they needed to be in to work correctly.  Looking at the datasheet, there is no WP line, but there is a HOLD line.  If HOLD is low, the serial interface of the chip doesn’t work.  I clipped one more logic analyzer line on to Pin 7 of the SPI RAM.  The signal looks identical to MOSI.  I should have cut the trace when I was re-wiring this board but I missed it. I proceeded to cut it and add a jumper from the HOLD line to the ESP12E Pin 11. this is my best guess for the pins to use SQI. With Re-testing I got a successful read from the chip.

SPI Successful read

Next week, I need to verify the SPI working registers have the expected values from the ram.  I put the current version of the code up on GitHub.

How do you handle cutting in circuit changes?  Do you have any stories about a design change only to find it best to go back to the original plan?

Understanding HSPI Firmware V00H

What I wasn’t understanding last week is the definition of HSPI_CS.  It is the same as CS0 in the HSPI module.  So when I turn on overlap mode, of course, it maps to SPI_CS0.  That leaves me with setting the HSPI to use CS1(GPIO1/U0TXD) or CS2(GPIO0).  Since I use U0TXD for reprogramming the module, CS1 is unavailable.

I cut the trace going to U2 CS0 and added a jumper wire to GPIO0.  I then changed the code to use CS2 to enable the RAM.  This included setting the HSPI to use CS2 and setting GPIO0 MUX to be SPICS2.  And I got what looks like a successful write to the SPI RAM.

Successful SPI Write

The byte command (2) followed by 24bit address (0) followed by the data.  The first four bytes of data are “lleH”.  This is backwards to what I was planning, I can change it by setting a bit or changing the bytes I put into the registers. As long as I read them back the same way, it really doesn’t matter as long as I read and write aligned to 4 byte words.  The data is one byte short, I had a typo sending only 11 bytes of data.

Note: When data is aligned to 4 bytes, it means you need to read or write only on increments of 4 bytes.  So you would only Write or Read to/from addresses that in hexadecimal end in 0, 4, 8, or C. Since this chip is a 32 bit processor, this is required often.

I then decided to implement the hard coded read command.  I copied the write code, changed the command from 2 to to 3, set the HSPI to read back  and zeroed out the working registers so that I can see if they have been filled with the data I stored in the RAM. Then I commented out the writeRam() call in user_init and added readRam() in it’s place. Doing this without powering down, I should get the data back without having to write it again. I forgot to switch the length to the receive length register; I fixed this then I got back all zeros for the data.

Unsuccessful SPI read

I see the command (3) followed by the address (0) followed by 12 Bytes of data(0). So I have more debugging to do.  My first guess is the WP or HOLD lines of the chip are not doing what I need them to do.

I have gotten a better understanding of the SPI hardware on the ESP8266.  It looks to me that I can get the same control by just using the main SPI channel to control my RAM chip.  This needs testing.  I will need to save any registers I change and restore them when I am done accessing the RAM.  This will also have to be done from code that runs from internal RAM.

I have put the current state of the code on GitHub.  Use the link under the search box on the right side of this page.

Have you used chips with similar SPI configuration?  I like that I can have any bit length of data on the SPI bus, this will be useful for JTAG data. Have you worked directly with JTAG data?

HSPI Frustrations

I cut the traces going to the SPI RAM that I figured out were wrong last week. On the PCB at U3 Pin3, and Pin5 I cut one trace each and on Pin6 I cut two traces.  Most of these cuts are under the chip so I made them before re-soldering the chip to the board.  Of course then I added wire jumpers to route the signals to match the schematic. I then added pins to connect the logic analyzer to.

Cut traces Chip Installed Rewired SPI

 

 

 

 

Last week I was looking at the the SPI driver code by MetalPhreak on Github as well as his blog to figure out how to send commands and data out and receive back over SPI.  The register SPI_USER is used to configure the SPI, SPI_USER1 sets up data length, SPI_USER2 sets up the command length and Command data.  Additionally, there is an SPI_Address Register that I can use to select an address in the RAM. Finally SPI_W0 to SPI_W15 are the data packet working registers — This is where I will put my “Hello World”.  I can write or read up to sixteen 4 byte words.  My RAM is organized in bytes so I will be putting bytes of data into the working registers.

So for initial setup I think the following should work for writing data.

SET_PERI_REG_MASK(SPI_USER(HSPI), SPI_CS_SETUP|SPI_CS_HOLD|SPI_USR_COMMAND|SPI_USR_ADDR|SPI_USR_MOSI);

CLEAR_PERI_REG_MASK(SPI_USER(HSPI), SPI_FLASH_MODE|SPI_USR_MISO);

 

The following should work for reading data:

SET_PERI_REG_MASK(SPI_USER(HSPI), SPI_CS_SETUP|SPI_CS_HOLD|SPI_USR_COMMAND|SPI_USR_ADDR|SPI_USR_MISO);

CLEAR_PERI_REG_MASK(SPI_USER(HSPI), SPI_FLASH_MODE|SPI_USR_MOSI);

The CS_SETUP and CS_HOLD parameters affect chip select timing. Setup is before clocking out data, hold is after.  Some chips need extra set up or hold time.  It will not affect performance significantly so I just turned each on by default so I don’t have to wonder if this RAM chip needs them. USR_COMMAND tells it to send the data in the command register. Likewise USR tells it to send the data in the Address Register.  USR_MOSI tells the hardware that there is data in the Working registers to be sent out. USR_MISO tells the hardware that I want to receive data into the working registers.

For the SPI RAM I want to send a command(Write), An Address(0), and 12 Bytes of data(“Hello World”).  This totals 16 bytes of data to be sent on the SPI bus:

1 byte for the command: 0x02
3 bytes for the address: 0x000000 and
12 bytes of data: “Hello World” including 1 trailing NULL.

For my first attempt to write to RAM I chose to hard code the instructions.
In my SPIRam.c File I had already created a function called writeRam.  I deleted it’s contents, and added the stuff to make this work.
void writeRam(char data[], int length){

SET_PERI_REG_MASK(SPI_USER(HSPI),
SPI_CS_SETUP|SPI_CS_HOLD|SPI_USR_COMMAND|SPI_USR_ADDR|SPI_USR_MOSI);
CLEAR_PERI_REG_MASK(SPI_USER(HSPI), SPI_FLASH_MODE|SPI_USR_MISO);

WRITE_PERI_REG(SPI_USER1(HSPI), (((12*8-1)&SPI_USR_MOSI_BITLEN)<<SPI_USR_MOSI_BITLEN_S)| //12 Bytes of data out
((7&SPI_USR_MISO_BITLEN)<<SPI_USR_MISO_BITLEN_S)| //Ignored for write
((23&SPI_USR_ADDR_BITLEN)<<SPI_USR_ADDR_BITLEN_S)); //address is 24 bits A0-A8

WRITE_PERI_REG(SPI_ADDR(HSPI),(uint32) 0x000000<<(32-24)); //write 24-bit address

WRITE_PERI_REG(SPI_USER2(HSPI),
(((7&SPI_USR_COMMAND_BITLEN)<<SPI_USR_COMMAND_BITLEN_S) | 0x02)); // Write Command

WRITE_PERI_REG(SPI_W0(HSPI),0x48656C6C); //"Hell"
WRITE_PERI_REG(SPI_W1(HSPI),0x6F20576F); //"o Wo"
WRITE_PERI_REG(SPI_W2(HSPI),0x6C6400); //"rld",NULL,NULL

SET_PERI_REG_MASK(SPI_CMD(HSPI), SPI_USR);// Tell hardware to do it.

}
After fixing my typos, I compiled and loaded the code.  The system booted without hanging. then I hooked up the logic analyzer to look for the data being transferred and it didn’t work. The Chip select line(U3 Pin1 ) doesn’t go low for a frame of data.  This means the chip never gets selected to write to.

With several hours of tinkering, I finally have it close, but it is still not working correctly.  The CS0 pin is being activated when the HSPI CS pin is being activated.  So I am getting the correct sequence of bytes when HSPI CS is low, but CS0 is low at the same time.

HSPI almost working

I have not posted a new copy of the software, I don’t believe it is useful to anyone yet.  It isn’t even useful to learn from.

Have you had similar frustrations? Have you gotten the HSPI to work in overlap mode?

Please leave a comment below.

 

Troubleshooting

I started out this week by hooking the SPI RAM to the logic analyzer. Then I hooked up the USB cable and it was stuck in a reboot cycle. I set the flash speed back to 20. Still stuck in reboot cycle. I disconnected the logic analyzer still in reboot loop.  I commented out the initSpiRam function in the startup code still stuck in reboot loop. This leads me to believe I have a power supply problem.

If it’s a power problem, adding large (100 μF) and small (0.01 μF) capacitors around the ESP-12E would solve the problem.  The 100 μF capacitor will act as an energy reservoir. The small capacitor will act as a noise filter. I piggy backed both a 100 μF and  a 0.01 μF capacitor on top of C4 the decoupling capacitor for the ESP-12E module. This didn’t solve the problem.  Next I suspected the SPI RAM was the problem.

I probed CS0 along with the SPI RAM CS line and they were in perfect phase.  This means that Q6 is not inverting the signal. This results with U2 on the SPI bus while the flash is being accessed.  That would definitely get it stuck in a reboot loop.  After feeling stumped for a while, I replaced Q6. It booted normally again. I uncommented the initSpiRam function and it started rebooting again. I tried with and without initSpiRam being called and it would consistently reboot when initSpiRam was called.

With initSpiRam uncommented, I went into the function and started commenting out lines to see what was causing the reboot.  It appears that ENABLE_SPI_DEV_CS() is causing the reboots. I moved it to after spi_master_init to see if that would work. spi_master_init(HSPI) by itself works. Next I tried adding overlap mode. It appears that overlap has to be after master init.  The SPI driver files and headers don’t have any way to read back data while in SPI master mode.

I decided to do a very simple test. I would do a SPI Master Write without overlap mode turned on. One write of one byte immediately after boot so it would be easy to catch on the logic analyzer.  The HSPI pins are:

GPIO14: CLK  Pin 5
GPIO12: MISO Pin 6
GPIO13: MOSI Pin 7
GPIO15: !CS  Pin 16

Chip select is the same pin I am already using, the rest are unconnected. I put a jumper across Q6 to always disable U2 by pulling CS (pin 1) high. I also soldered test points to each pin so I could easily attach the logic analyzer. With the jumper across Q6 I couldn’t even program the board!  This doesn’t make sense, I’ll have to come back to that.  I think I have some mis-wiring. I removed U2 from the board, and this allowed me to reprogram the PCB.

It now boots but doesn’t give me a menu. It appears to hang on the spi_mast_byte_write() call.

This is not a big deal, I haven’t set the SPI port.

All that time spent fighting this problem, and it turned out to be a solder bridge between R27 and a PCB trace from FLASH CS0.  I cleaned up this bridge and it started working reliably.

Finally I tested the basic HSPI write function. It didn’t work. but code is running without freezing or rebooting.  So I added a call to spi_master_init() still not working, no data on lines.  Looking in spi.c, I saw that spi_master_init() doesn’t assign pins to the HSPI port.  I added the lines below to user_init(). HSPI_PIN is defined as 2.

PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTMS_U,HSPI_PIN); // GPIO14
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDI_U,HSPI_PIN); // GPIO12
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTCK_U,HSPI_PIN);// GPIO13
PIN_FUNC_SELECT(PERIPHS_IO_MUX_MTDO_U,HSPI_PIN);// GPIO15

And I saw a byte on the logic analyzer. Yeah! progress.

SPI Byte outThe data speed is at 20MHz. I tried two writes in a row and got a chip select active for each write, and inactive in between. I need to figure out how to change this behavior, the SPI RAM commands always follow the falling(going active) edge of chip select. To write data to the RAM, I have to send more than one byte while chip select is active.

How do you do troubleshooting? Have you gotten HSPI Working on the ESP-12E? Does anyone know if there are different pinouts for the ESP-12E? Something I saw suggested to me that I still have the SPI RAM connected wrong again.

New PCBs

The PCBs arrived this week.  I really like the way my Logo came out.  20160415BarePCB

I do want to make an adjustment, make the arrows larger, they didn’t even show up on the silkscreen.

PCBLogo

To start testing, I put a jumper in bypassing the lithium cell charger. I then installed the ESP-12E, the SPI RAM, The Crystal, the USB Serial Bridge, the voltage regulator, and the USB connector. Just enough to power up, load a program and test the basics.

20160415assembledPCB

First test was to  connect to PC and run ESPlorer– it worked.

I got a message:


AT-based firmware detected.
AT+GMR
AT version:0.40.0.0(Aug 8 2015 14:45:58)
SDK version:1.3.0
Ai-Thinker Technology Co.,Ltd.
Build:1.3.0.2 Sep 11 2015 11:48:04

I then tried to install my test version of the software and it wouldn’t install.  I went back to ESPlorer and started playing with the DTR and RTS to see what would happen. It turns out I got DTR and RTS backwards. So I cut the traces and added a couple of jumpers. This is the kind of mistake I was hoping to catch in the design review.

It programmed great with the wires swapped. My code crashed, back to a “Hello World” version.

Turns out the internal memory chip installed on the ESP-12E does not run at the settings I had specified with esptool.py.  I found this out by setting it to 20MHz DIO mode which started working. I then switched it to QIO mode to see what happened. QIO worked, next I tried running at 40 MHz. That worked.

../esptool/esptool.py --port /dev/ttyUSB0 --baud 230400 write_flash -ff 40m -fm qio -fs 32m 0x00000 ../bin/eagle.flash.bin 0x40000 ../bin/eagle.irom0text.bin

I enabled HSPI Overlap mode by adding spiRamInit() to the end user_init(). Ran without crashing. When I started building for use, I discovered no SPI Master Read available.  I saw something that looked correct for slave read, so I borrowed a line from it and did a write followed by that line– it built. I uploaded the code, and it ran, still no testing of the SPI Ram.

I added the function calls to write “Hello World” to the SPI RAM. and read back and put out to the console. and I got garbage back to the console.  Not a surprise. Debugging with a logic analyzer next week.

Have you written code for the ESP8266. Have you worked with SPI before? I would love to Hear from you.

 

Hardware SPI test software (Firmware V00G)

The PCBs haven’t arrived yet.  So, I worked on the test code for the SPI ram.

Using the datasheet, I started setting up for SPI overlap mode.  On the ESP8266 there are two hardware SPI modules.  In overlap mode, they share the same pins.  This means that if you use the second SPI module you can directly work with the flash memory by using CS0 for the chip select.  I don’t see a lot of use for that other than for performance.  If you choose a different chip select, like I am using GPIO15. You are just sharing the pins with the processor. You have to make sure your code will run in RAM while using the second SPI.  ESP8266 documentation calls the second SPI HSPI.

From Microchips 23LC1024 datasheet, the sequence to write to the SPI RAM in sequential mode is:

Set CS low, write out the value 2 MSB First followed by the 24bit address to start writing at(in 3 bytes), followed by the data to be written(as many bytes as wanted up to the size of the RAM) followed by setting CS high.

A Sequential read has the following steps:

Set CS low, Write out the value 3 MSB first followed by the 24 bit address, then read in as many bytes as wanted. Then set CS high.

Side Note: MSB means Most Significant Bit.  Some protocols transfer in the opposite order or LSB first.  It is important to know this when setting up any serial communication. Data is clocked out on the falling edge of SCK and latched on the rising edge of SCK.  The inactive state of SCK is low.

To help out Espressif provides a guide called:

ESP8266 SPI Overlap & Display Application Guid

This guide describes the SPI Overlap mode API as well as gives a reference implementation using an LCD.  Unfortunately this document is missing a lot of useful information.  There is a post on Espressif’s forum describing it and showing an example.

To get started I have created two new files SPIRam.c and SPIRam.h.  This will make the code easier to locate and modify. To begin with I just want to write some data, and read it back and send it out on the serial connection. Basically a Hello World on the SPI RAM

I created 3 functions:

initSpiRam(); // Set up SPI and Overlap Mode
disableSpiRam(); // Shut down Overlap Mode
writeRam(char data[], int length);
readRam(char data[], int length);

I got it to build but I am unable to test it.

I still have to add a couple of commands over the serial port to tell it to write and tell it to read. I pushed a copy up to Github

I’d like to hear about the projects you are working on.  Please leave a comment below.

SPI RAM

I am anticipating the new PCBs coming in soon, (I have a tracking number but it doesn’t show up with Hong Kong Post or USPS). In light of this, I decided to do a little research on the SPI RAM so that when it gets here, I can quickly write code to test the functionality of the design.  The SPI RAM I have chosen is a 23LC1024.  A common manufacturer of this chip is MicroChip, I downloaded their datasheet for this chip and started looking at the process to write to and read from the RAM.

Notes for writing to SPI RAM:

Maximum 20 Mhz Clock for all data transfers (might cause me to slow down the FLASH)

Write speed only limited by clock speed.

Write command(0x02) followed by 24bit address followed by data

Page Mode 32bytes before sending a new address

Sequential mode can fill the whole RAM

Write is terminated by CS going inactive(HIGH)

Notes for reading from RAM

Same maximum clock speed.

read only limited by clock speed.

Read command(0x03) followed by 24bit address start receiving/clocking data from RAM

Three modes of operation, Byte, Page, and Sequential.

Byte mode only allows reading/writing one byte before having to resend an address.

Page mode all data is accessed in pages of thirty two bytes. Not very useful for this project.

Sequential mode allows access to all of RAM as one big block that I can start accessing from any point. I need to set the mode register bits 7 and 6 to 01.

I am going to start in standard SPI mode, Make sure it is working then adjust the code to start taking advantage of the SQI interface.