- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Original question:
MCU-PLUS-SDK-AM243X: loadCpus sometimes asserts in DMA access
Hello,
we tried updateing the SDK to 08.05 and postponed the new flash-driver in 08.04 already. So we wanted to finally update it but experiences problems as described in https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1189521/mcu-plus-sdk-am243x-loadcpus-sometimes-asserts-in-dma-access/4521992#4521992
with the IS25WX256T it does not seem to work, at least the read data is not correct.
I will copy the observation from the other thread:
so I compared the init of both sdks. First I let the old one run, which works. I copied all the issued flash-cmds for config inside Flash_norOspiOpen and copied the register values to compare them. The only difference I see is the order of the address-byte setting. But the registers seem to be the same in the end. I let both run until
since this is the point where we get different results when reading the flash.
Every indendation means this is the value/call inside the function above.
for the old working drivers:
for the new updated - not working - driver:
I also noticed that, when trying to do a CPU reset via ccs and load the image again after the call of the mentioned OSPI_phyReadAttackVector, the first read in SDR config won't work anymore and thus we can't read out the flash-id. We do - independently of the driver - have the same sequence you use in your driver-example:
This always worked with the old driver. With the new driver we need a power reset of the device to get this working. Else the read stuff is not correct. I guess the driver configures something different here but I don't know what.
Also some screenshots of how the read out memory looks after the call of OSPI_phyReadAttackVector at 0x60000000 via memory browser:
old driver:
it seems only some values match and then somehow all memory after that has the same value. Maybe that helps to identify the problem better.
Additionally here is our new configuration that I migrated:
is there maybe another point inside the sdk that was changed that could have an impact here? But all other drivers are working fine. mcspi, pruicss, icssemac, clock, hwtimer, adc, gpios and so on are working as expected.
Also pls mention: I removed the subsequent Flash_norOspiReadId of the new driver, which was used to calculate the readDataCapDelay, since this never worked (it counted down to 0). I just set it hard to 3 which was the value of the old driver. But also this did not work.
The setting of the old driver were:
We need the flash-driver to be working with the new sdk.
Best regards
Felix
Hi Felix Heil,
I had a discussion with the expert and it was understood that the flash part supports only upto 1D-8D-8D which is not supported via syscfg. So I would recommend to use this function to bypass the syscfg -
And use the older flow of the driver in this function.
Hope it resolves your problem.
Best Regards,
Aakash
Hey Aakash,
the correct ident of the flash is IS25WX256. The datasheet says:
and
The datasheet should be available for free online.
Best regards,
Felix
Hey Aakash,
thanks for the Json. I tried to load is but an exception happens:
I tried it with SysCfg 1.14 and 1.15. Both run into this.
Best regards,
Felix
Hi Felix,
Please try the following fix -
1. So to fix these, firstly the correct copy command executable must be added i.e., "cp.exe" under the path C:\ti\<CCS_Version>\ccs\utils\cygwin to the environment variable as shown below, (confirm this by typing cp in the command line without any arguments and it should through an error "cp missing file operand")
2. Next step is to edit the flash_v0.syscfg.js file, in the line number 7 from "copy --> cp" as shown below
Now, save everything and try loading the JSON file in the sysconfig again.
Hope it helps.
Best Regards,
Aakash
Hey Aakash, I tried the fix, now it loeads but then shows:
as the Flash name and no data is changed (still the default config)
Hey Aakash,
I tried loading it, and it worked so far, but the values don't seem to be taken correctly:
Right is the one you just sent me, left is what SysCfg changed and did not change. Is this the correct behaviour?
Hey Aakash,
so I tried the setting it with the values of the file you gave me ( I also needed to change the sdk-verswion inside the file to 08.05 to be able to open it in SysCfg) but unfortunately now it hangs here:
It can't escape this while-loop:
Best regards,
Felix
On Tuesday i have some free time windows. I will write you a mail.
a dump of the flash only gives me this:
and OSPI-regs:
or as memory dump directly:
Hi Felix Heil,
As discussed in the call -
1. The sysconfig was not able to do the protocol writes hence, the suggestion is to comment out the Flash_norOspiSetProtocol and use the function in the attached file.
2. Also the dummy cycles was not being written for this flash due to
Skip this part of code as somehow ISSI flash is only able to read 1byte of data
Best Regards,
Aakash
Hello Aakash,
Yes this is one part of the solution.
I noticed that this alone won't fix it. The data which was read was somehow looking correct but in fact was not.
The data I read after our debug-session was:
correct data will look like this:
I needed to change a bit more. I followed the old working driver and here I saw that the address-byte-number was changed to 4 before setting to OCTAL-SPI. The new driver maybe get confused because it sets the address-byte-number after OSPI-Part is being set to OCTAL-SPI. But as I understood at least the ISSI can only talk with 4-Byte-Address in OCTAL-SPI. So calling a command of address-byte setting after the OCTAL-SPI was configured with the previous 3-byte-address-setting, this would probably not work.
So I did it like this:
Which means my Flash_norOspiSet8D_ISSI only reaches until line 16 of your post, the rest is done before.
Also I noticed that the wait-ready function which was working in the old driver had some different settings so I tried it like it was before (else if):
But noticed that it doesn't matter if or if not the else if is taken. Behaviour seems to be the same.
Also the reg-read patch was done like this currently:
which works so far as well.
Also I changed the extCmd from REPEAT to INVERSE since this was the setting for the old driver.
I came to this point when setting the dummycycles (OSPI already configured to OCTAL). Right before OSPI_setReadDummyCycles data was wrong. right after OSPI_setReadDummyCycles data is correct:
from here on I checked the next functions. The Flash_norOspiSetRegCfg is called. Inside the patched Flash_norOspiRegRead is done which only reads 1 Byte. Data looks like this, but I guess that's ok in this case since the cmd-read was triggered? 1F is at least the value expected from the ISSI-register
Then the Flash_norOspiRegWrite is called. It works as far as I get into the wait-ready:
were you can see the data is there, but repeated.
But I think that's ok, since the dummycycles are not yet written. after calling the following Flash_norOspiCmdWrite-function, and before calling the next WaitReady it looks like this:
after calling:
And there I am currently. So it seems that in-between, when the dummy-cycles are set in OSPI the data seems to be read correct but somehow it gets wrong after configuring the ISSI to 16 dummycycles.
The WaitReady can be as patched like the old driver or not changed like in the new driver. the behaviour is not changed by that.
maybe this helps a bit more to identify the problem.
I really liked the good teamwork and progression last debug-session so if you want we can start another session again.
Best regards
Felix
