What’s “the second packet is omitted”? Does that mean
you write to the SRAM, but the data doesn’t go to the SRAM
at all?
If the problem is timing, I’d rather to change the
timing setting register than add delay.
Wensheng
Jacek Rudnicki wrote:
I did once again test with raw partitions.
In result flash is working fine while there is
small problem with SRAM write function.We suppose that problem comes from
timings settings. Our SRAM needs a little
more time for write completion than flash
device.So, we added delay to the write routine.
Now function is working ok (writes data
properly) but there is another problem with
sequence of data packets:a) first packet is wirtten properly,
b) the second packet is omitted,
c) third packet is written twice.The a) and b) point are repeated from
time to time.Do you know what I should to do now?
Jacek
Uzytkownik “Wensheng Zheng” <> wzheng@qnx.com> > napisal w wiadomosci
news:dcvkt7$gpg$> 1@inn.qnx.com> …Do you have file system on your flash?
Try to copy to/from raw partion “/dev/fs0”
or “/dev/fs1”. For flash, make sure the flash
is blank before copy data to it.
Wensheng
Jacek Rudnicki wrote:There are some distortions beetween
original file and data read back.Very interesting is that distortions
come also from flash with works
without any problems.I tried to read partition by cp command
and dd utility as well.So, does this method is good for testing?
Jacek
Uzytkownik “Wensheng Zheng” <> wzheng@qnx.com> > napisal w wiadomosci
news:dct5pn$lej$> 1@inn.qnx.com> …
Could you please write exactly 256K file to that partition
and read it back to compare the result?Wensheng
Jacek Rudnicki wrote:
For me write/read function looks ok.I copied text file into SRAM partiton
ecp test1.txt /dev/fs1p0
and next I read it back
ecp /dev/fs1p0 /tmp/dump.txt
In result beginning of dump.txt is
the same as test1.txt file. No distortions.We set everything what is needed
for flash filesystem and I have no idea
why mounting still is failing.Maybe should I send to you two
dumpped partitons for comparison?One from our SRAM, and the second
from flash (in the same organization)
which works fine.
Does it help?
Jacek
Uzytkownik “Wensheng Zheng” <> wzheng@qnx.com> > napisal w wiadomosci
news:dcqfes$kt3$> 1@inn.qnx.com> …
Something wrong with your write/read function,
dump the memory after you write to the sram to
see if the value is correct.
Depends on how you wired the SRAM, you may need
to shift the value like:
(*((volatile uint16_t )(b + ((o + c) << 1)))) = val << 8;
or just simply do a 8 bit access
(((volatile uint8_t *)(b + ((o + c) << 1)))) = 8;Wensheng
Jacek Rudnicki wrote:
Result is the same.Uzytkownik “Wensheng Zheng” <> wzheng@qnx.com> > napisal w wiadomosci
news:dcqd1j$j4s$> 1@inn.qnx.com> …
Try bus width 1 (8 bit bus).
Jacek Rudnicki wrote:
Here is our devf-sram output:calloc f3s_start, 181: 0x80
calloc f3s_start, 211: 0x40
calloc f3s_start, 235: 0x30
calloc f3s_start, 257: 0x48
calloc f3s_start, 271: 0x98
devf: fs1 socket viper-sram
devf: chip total = 1
devf: bus width = 2
devf: chip interleave = 1
calloc f3s_array_alloc, 21: 0x18
calloc f3s_array_alloc, 22: 0x400
calloc f3s_array_alloc, 23: 0x200
calloc f3s_array_alloc, 24: 0x100
calloc f3s_array_alloc, 25: 0x100
calloc f3s_array_alloc, 26: 0x400
malloc f3s_array_alloc, 27: 0x2400
devf: fs1 array SRAM U: 100 S: 000400
malloc f3s_array_attach, 135: 0x10
calloc f3s_array_attach, 139: 0x80
calloc f3s_array_attach, 140: 0x80
calloc f3s_array_attach, 143: 0x88
calloc f3s_array_attach, 146: 0x30
calloc f3s_array_attach, 147: 0x30
devf: fs1p0 raw U: 100
devf: fs1p0 raw U: 100Jacek
Still could be your read and/or write function are not implemented
properly.
What’s your devf-sram -vvvvvv output?Wensheng
Jacek Rudnicki wrote:
Hi Wensheng,After “f3s_sram_v2read” and “f3s_sram_v2write”
function modification I can erase and format the
SRAM device, but I have problem with mounting it:flashctl -p/dev/fs1p0 -e -f -n /sram -m -vvvvvvvvvvvvvvv
Erasing device /dev/fs1p0
offset = 0,limit = 40000
…
Formatting device /dev/fs1p0
Mounting device /dev/fs1p0 at /sram
DCMD_F3S_MOUNT failed (errno 302)
flashctl: mounting partition failedflashctl -p/dev/fs1p0 -i
Array Info
Total : 0x00040000 100%
Chip Size : 0x00040000 100%
Unit Size : 0x00010000 25%
Part Info
Total : 0x00040000 100%
Spare : 0x00000000 0%
Headers : 0x00000000 0%
Padding : 0x00000000 0%
Overhead : 0x00000000 0%
Free : 0x00000000 0%
Stale : 0x00000000 0%
Avail. : 0x00000000 0%
Reserved : 0x00000000 0%Do you know what else can be wrong?
Thank you,
JacekUzytkownik “Wensheng Zheng” <> wzheng@qnx.com> > napisal w wiadomosci
news:dcdehq$5bv$> 1@inn.qnx.com> …
You can re-write your read function like
int32_t
f3s_sram_v2read(f3s_dbase_t * dbase,
f3s_access_t * access,
uint32_t flags,
uint32_t offset,
int32_t size,
uint8_t * buffer)
{
uint8_t *memory;
uint32_t cnt;
uint32_t base;/* set proper page on socket */
memory = access->service->page(&access->socket, F3S_POWER_ALL,
offset, &size);if (!memory)
return -1;/* There is only one page for SRAM */
base = (uint32_t)memory - offset;for (cnt = 0; cnt < size; cnt++)
buffer[cnt] = (*((volatile uint16_t *)(base + ((offset +cnt)
1))));return size;
}
Jacek Rudnicki wrote:
Ok, but what is about read function which is hidden inside the
libfs-flash3.a library?
I can modify existing erase/write routine but I have no ideahow
to
play
with read.Where can I find more information about that?
Jacek
Uzytkownik “Wensheng Zheng” <> wzheng@qnx.com> > napisal w
wiadomosci
news:dcdapt$2st$> 1@inn.qnx.com> …
You are right, you have to write your own read/write/erasefunction.
Jacek Rudnicki wrote:
Hi,At the moment we are developing custom driver
for the SRAM device and arm platform.The static memory is a 8-bit device which works
on the 16-bit bus and with each 2 bajts
addressing (offset: 0,2,4, etc.).In practice 256K of SRAM are visible in the
memory map as 512K device with holes
at base address + 1 ,3 , … .How can I handle this device?
To my knowledge read & write routine included
in libfs-flash3.a library doesn’t handle such
scenario. Am I right ?Jacek
\