Electronics > FPGA

FPGA VGA Controller for 8-bit computer

<< < (669/681) > >>

nockieboy:

--- Quote from: BrianHG on May 22, 2022, 05:48:58 am ---Arrrg, 3 days... 3 days of trying to track down this silly bug where a read port may freeze when running my DDR3 controller in Quarter Rate Mode with an unusual slip in the read address (when slanting 1 of 2 superimposed video layers on my VGA controller) only after millions of read commands issued.  I just cant simulate it and the signal tap would be useless as there are too many environment variables to track at 300MHz.  It's driving me nuts as it is the one thing I have left before issuing a proper v1.6 release.  There is no reason for this to operate properly in half-rate mode, but not quarter-rate mode and I know which modules are involved.  Worse, turning off the read-cache solves the problem at the expense of making repetitive reads slow.
--- End quote ---

Eesh - didn't realise it was such a pervasive little problem! :-\

I'll take a look at the updated DDR3 controller this weekend and update my project with it.

I've managed to keep plugging away at the SD interface this last week or so and have made some significant progress - I'm now at the testing and bug-hunting stage, having written a WRITE function for the interface.  It is somewhat based on the existing SDReader module, but I've leaned heavily on the HDL within the SD-card-controller sd_data_serial_host module for guidance.  I've also been deep-diving the SD Part_1_Physical_Layer_Specification (albeit version 3.01, but it's not the simplified version and has some key diagrams showing WRITE timings).

I'm reading Sector 0 off the SD card into the SD Buffer in GPU RAM.  Then I'm trying to write that data (the FAT32 MBR, basically) to Sector 3.  I'm writing it to Sector 3 as Sector 3 appears to be all zeros on the SD card, and failed writes erase the sector but don't write anything, so I'm not changing any data on the SD card with a failed write (which is all I'm managing to do at the moment).

It appears that I'm not getting anything back from the SD card when I attempt to write to it.  I'm sending CMD24, then writing the 512-byte payload, immediately followed by the 16-bit CRC and STOP bit, but I'm not seeing any life on DAT0 when the SD card should be responding with the CRC response byte (which should be an error or OK, if I've got the CRC function working correctly).

Here's a SignalTap of the start of the process, showing the start of payload transmission to the SD card (CMD24 is sent using the same module that the READ command is sent, I have no reason to think it's not working as intended):



And here's a SignalTap of the end of the process, showing the last two bytes of the payload (0x55 and 0xAA being the last two bytes of Sector 0) and the 16 CRC bits and STOP bit:



It seems there are quite a few possible points of failure in this process - I'm gravitating towards it being an issue with the DAT0 direction or the CRC being incorrect, but the SD card should respond if it's a CRC error.

I'd really, really appreciate the help of anyone who knows a bit about the SD interface and 1-bit SD mode, which is what I'm using here.  Latest project files attached for reference.  The SD modules are in the SDCard_Interface folder in the project folder - SDWriter is the module that I'm debugging. :-/O

BrianHG:
Question, don't you have to erase a block to change all the bits from 0's ti 1's, then, whatever you write, only 0's are actually written.  Meaning you can progressively keep on writing again and again changing any 1's to 0's, but once the bit is 0, you cannot flip it back to a '1' unless you do a block/sector erase with erases an entire chunk at once.

nockieboy:

--- Quote from: BrianHG on May 27, 2022, 08:12:30 pm ---Question, don't you have to erase a block to change all the bits from 0's ti 1's, then, whatever you write, only 0's are actually written.  Meaning you can progressively keep on writing again and again changing any 1's to 0's, but once the bit is 0, you cannot flip it back to a '1' unless you do a block/sector erase with erases an entire chunk at once.
--- End quote ---

I must have missed everything in the specification documents and even HDL examples I've been using where any kind of erase is performed before a write.  As far as I can tell, the SD card erases the sector when the write command is issued, then writes the new 512 bytes of data to the sector from its internal buffer once it has all been received and the CRC checks out.  Pre-erase seems to be for multi-block writes - you can let the SD card know how many blocks you intend to write and the SD card can pre-erase those blocks before you send all the data, eliminating the pauses between each block write whilst it erases the next block.

At least, that's how I understand it, but I've not actually read anything in the specification documents explicitly saying that's how it works.  This flowchart in the specifications also makes no mention of pre-erase for single-block writes:



Of course, there's always the possibility I'm wrong - it isn't exactly unheard of.  ;)

EDIT: Also, when I've accidentally written to Sector 0, it has been set to all zeros.

BrianHG:

--- Quote from: nockieboy on May 27, 2022, 07:16:48 pm ---
--- Quote from: BrianHG on May 22, 2022, 05:48:58 am ---Arrrg, 3 days... 3 days of trying to track down this silly bug where a read port may freeze when running my DDR3 controller in Quarter Rate Mode with an unusual slip in the read address (when slanting 1 of 2 superimposed video layers on my VGA controller) only after millions of read commands issued.  I just cant simulate it and the signal tap would be useless as there are too many environment variables to track at 300MHz.  It's driving me nuts as it is the one thing I have left before issuing a proper v1.6 release.  There is no reason for this to operate properly in half-rate mode, but not quarter-rate mode and I know which modules are involved.  Worse, turning off the read-cache solves the problem at the expense of making repetitive reads slow.
--- End quote ---

Eesh - didn't realise it was such a pervasive little problem! :-\

I'll take a look at the updated DDR3 controller this weekend and update my project with it.

--- End quote ---

Once in a few hundred million bytes causing a random freeze is sometimes tough to find the true root cause, especially if it has more than one problem behind it.

No update yet.  I have some other priorities which is sapping my time.

pcprogrammer:
@nockieboy

About the SD card write you are correct that the card does the erase when needed. Before sending command 24 you have to select the card with command 7 and only when it returns an OK it is ready to receive the write command.

When there are multiple 512 byte blocks to write you have to use command 25.

At least this is how it works for me in the FNIRSI 1013D. I guess you have to also get the low level interfacing done to make it work. The F1C100s has a dedicated SD card interface that takes care of this.

As I wrote before look at the code here https://github.com/pecostm32/FNIRSI_1013D_Firmware/blob/main/fnirsi_1013d_scope/sd_card_interface.c

The function "int32 sd_card_write(uint32 sector, uint32 blocks, uint8 *buffer)" takes care of the users write request by calling the function "int32 sd_card_send_command(PSD_CARD_COMMAND command, PSD_CARD_DATA data)" with the needed commands.

This latter function does the controlling of the F1C100s low level SD card interface peripheral.

The card also has to be in the correct state to be able to select and deselect it. This is done with the "int32 sd_card_init(void)" function.

Hope this helps.

Cheers,
Peter

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version