The m25q driver doesn't work with the Macronix flash found on the 32F723 Disco and 32F769 Disco.
Its not as simple as adding the device ID to the list, although that is necessary.
The Macronix flash on the 32F769 has ID 0xc2 0x20 0x1a.
Looks like it needs different QSPI settings. (Only had a very quick test)
Note: if a driver supports multiple manufacturers' devices, the device id check needs to do a string (array) compare, rather than checking first the manufacturer then the rest of the ID
QSPI Driver Topic is solved
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: QSPI Driver
Hi,
The M25Q driver is for a very specific Micron devices family (M25Qxxx). Flash devices have command differences and different timings, a new driver is required, probably similar but now quite the same. Only a small subset of commands is "standard".
Drivers support specific families, not the whole devices class.
Giovanni
The M25Q driver is for a very specific Micron devices family (M25Qxxx). Flash devices have command differences and different timings, a new driver is required, probably similar but now quite the same. Only a small subset of commands is "standard".
Drivers support specific families, not the whole devices class.
Giovanni
Re: QSPI Driver
Giovanni wrote:The M25Q driver is for a very specific Micron devices family (M25Qxxx). Flash devices have command differences and different timings, a new driver is required, probably similar but now quite the same. Only a small subset of commands is "standard".
Drivers support specific families, not the whole devices class.
I only mentioned it because in an earlier thread you explained that the driver was called "m25*" rather than "n25*" in the hope (expectation?) that it would also work with the Macronix part.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: QSPI Driver
Probably I forgot that initial idea, I decided to make it per-family because the code would grow by adding support for many devices.
There are two options:
1) Try to add other devices support in there (and have switches for enabling/disabling them).
2) Rename that driver to N25Q.
Giovanni
There are two options:
1) Try to add other devices support in there (and have switches for enabling/disabling them).
2) Rename that driver to N25Q.
Giovanni
Re: QSPI Driver
Giovanni wrote:There are two options:
1) Try to add other devices support in there (and have switches for enabling/disabling them).
2) Rename that driver to N25Q.
I'm in the process of supporting another memory type, and there are certainly a lot of similarities/commonalities between the drivers. Main differences appear to be the method of switching in and out of XIP mode, and reset. Also I can send all commands in 4-bit mode, once the memory is in QSPI mode.
Given the vagaries of memory supply at times, I think the holy grail is an option to identify the part that is actually fitted at run-time, and select the appropriate driver. (Possibly with the option to force a particular device by external means). So maybe borrow from the HAL structure, and have a top-level driver for management, and low-level drivers/tables for device-specific.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: QSPI Driver
That is worth considering. The parts you already identified is where most differences are.
Probably we should have a base driver a series of headers, one for each device exporting the command definitions, device id and code snippets embedded in macros to be included in the main driver.
Each device should then have an enable/disable switch or code size would explode.
The main problem I see right now is the reset procedure, it is performed before device identification so you don't know which reset procedure to perform.
The solution would be to select statically the device, not at runtime, it would be a configuration option. This would prevent the driver to work with multiple devices at same time however.
Giovanni
Probably we should have a base driver a series of headers, one for each device exporting the command definitions, device id and code snippets embedded in macros to be included in the main driver.
Each device should then have an enable/disable switch or code size would explode.
The main problem I see right now is the reset procedure, it is performed before device identification so you don't know which reset procedure to perform.
Code: Select all
/* Attempting a reset of the XIP mode, it could be in an unexpected state
because a CPU reset does not reset the memory too.*/
m25q_reset_xip(devp);
/* Attempting a eeset of the device, it could be in an unexpected state
because a CPU reset does not reset the memory too.*/
m25q_reset_memory(devp);
/* Reading device ID and unique ID.*/
qspiReceive(devp->config->busp, &m25q_cmd_read_id,
sizeof devp->device_id, devp->device_id);
The solution would be to select statically the device, not at runtime, it would be a configuration option. This would prevent the driver to work with multiple devices at same time however.
Giovanni
Re: QSPI Driver
I'd also identified reset as the main problem.
I think things are standard once in 1-bit (SPI) mode.
So maybe run through a number of multi-bit reset sequences, then the 1-bit sequence.
I think things are standard once in 1-bit (SPI) mode.
So maybe run through a number of multi-bit reset sequences, then the 1-bit sequence.
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: QSPI Driver
Hi,
I committed an experimental rework of the M25Q driver that is layered as proposed.
It is under /os/hal/lib/complex/m25q and should simplify the implementation of new devices, not tested yet but I mainly moved existing code around.
Thoughts?
Note: backport to 18.2.x is possible.
Giovanni
I committed an experimental rework of the M25Q driver that is layered as proposed.
It is under /os/hal/lib/complex/m25q and should simplify the implementation of new devices, not tested yet but I mainly moved existing code around.
Thoughts?
Note: backport to 18.2.x is possible.
Giovanni
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: QSPI Driver
Giovanni wrote:Hi,
Anybody had a chance to try the new driver?
Giovanni
Not me, I'm afraid - using a different flash chip, and while my driver badly needs cleaning up, it does at least work!
Who is online
Users browsing this forum: No registered users and 25 guests