K22 FTFE 'Read Resource' Command: Where is the actual data in FCCOB?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K22 FTFE 'Read Resource' Command: Where is the actual data in FCCOB?

1,151 Views
scottthompson
Contributor II

Greetings,

I'm using FTFE flash in a MK22FX512VLL12 device and have kludged in some capabilities for FlashX support in MQX based on FTFL drivers.

From the reference manual for the MK22FX device, the Data Flash 0 IFR section should have the EEPROM and DEPART codes at the following locations:

pastedImage_0.png

For the Data Flash 0 IFR, our resource select code is 0x00 and the local address range is 0x80_0000–0x80_03FF.

Data in FTFE is big-endian, and the flash address must be 64-bit aligned, which means I need to read at 0x8003F8 to get the start of my block that will index into the IFR.

According to the reference manual (again), the following FCCOB registers highlight the corresponding data returned:

pastedImage_1.png

Using a DSTREAM ICE, the corresponding FCCOB registers that are returned from a previously partitioned device are:

pastedImage_2.png

The indices in command_array (above) correspond directly to the FCCOB number, so FCCOB[0] = 0x03, which is the Read Resource command.  The address is 0x8003F8, and so forth.  I am reading in the full 12-bytes from FCCOB.

Since I expect my data to be at 0x03FC, 0x03FD, and my 8-byte buffer (now in FCCOB) starts at 0x03F8, I should expect my data to be in FCCOB[6] and FCCOB[7] (right?).  Yet, looking at FCCOB[6] and FCCOB[7], above, we see that these are 0xFF bytes.  It almost appears that the actual EEPROM data size (and split) and DEPART codes are stored at FCCOB[A] and FCCOB[B].

Note: reading the SIM_FCFG1 register gives me valid results for EESIZE and DEPART, and I can start to use that to determine if the partition is created, but all of our other code relies on the Read Resource command and I'd like to understand this better anyway...

(For completeness, I've included the EESIZE and DEPART codes so it can be seen that command_array[10], command_array[11] might actually contain valid partition codes.)

pastedImage_3.png

pastedImage_4.png

My goal is for EESPLIT to be 0x3 (1/2A + 1/2B), EESIZE to be 4096 Bytes (EEPROM code = 0x32), and for the partition code to be 64 kB Data Flash and 64 kB EEPROM Backup (16x 4 kB) (DEPART = 0x4).

Thanks for any insights, Freescale Community :smileyhappy:

0 Kudos
4 Replies

597 Views
melissa_hunter
NXP Employee
NXP Employee

Hi Scott,

I would expect the values you are looking for to be returned in command_array[8] and command_array[9], but I do agree that what is coming back in command_array[10] and command_array[11] appear to be the values you are trying to find. Are you sure the array is directly mapped to all the FCCOB registers? Unfortunately the standard tower board we use for that part uses a part that doesn't support FlexNVM, so I don't have a hardware setup at my desk that I can use to double check this. Overall, using the SIM_FCFG1 is a much easier approach, and you won't have to worry about endianness of the data.

Regards,

Melissa

0 Kudos

597 Views
scottthompson
Contributor II

Thank you, Melissa, for helping to confirm some of what I suspected.  I'm so used to thinking in little-endian that I may have forgotten some of the nuances of multiple-byte conversion from LE to BE.  Looks like the C90TFS driver swaps entire long words and then swaps the bytes as well, but even taking various permutations of endianness conversions, I can't reconcile why the EESIZE, EESPLIT, and DEPART codes are showing up where they are.

For now, I have switched my partition checks for all of the K10, K22, etc. devices to use SIM_FCFG1 to check the partition code.  It looks like the FTFL and FTFE write partition commands work as expected, so that's good (i.e., the values programmed end up getting reported back in SIM_FCFG1, just not in the Read Resource data).

Again, I appreciate the feedback and confirmation.

Best,

Scott

0 Kudos

597 Views
Hui_Ma
NXP TechSupport
NXP TechSupport

Hi,

I had checked K22 related validation report file and errata file, there without related record about Read Resource Command report the Data Flash IFR with mis-order data.

You are right, the EEPROM Data Set Size located at 0x3FD and FlexNVM Partition Code located at 0x3FC, which should be at FCCOB[6] and FCCOB[7].

While, I don't have K22 with FlexNVM chip on hand. I could not do the same test.

If customer could try the latest Kinetis Software Development Kit (KSDK).

There with the Flash example, customer could try Read Resource Command and check if there with the correct order of FCCOB return value.

C:\Freescale\KSDK_1.2.0\examples\frdmk22f\driver_examples\flash

Wish it helps.
Have a great day,
Ma Hui

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

597 Views
scottthompson
Contributor II

Hello, and thank you for your response to my post.

I have installed the Freescale Kinetis SDK and browsed through the FRDMK22F flash example, and other flash examples.  None of the devices have FlexNVM memory, but I was able to pick though the source code for the C90TFS code and see that the read resources command here returns the following mapping for little-endian:

command_array index               FTFL FCCOB Number                FTFA FCCOB Number (C90TFS source)

0                                                  0                                                 7

1                                                  1                                                 6

2                                                  2                                                 5

3                                                  3                                                  4

4                                                  4                                                  B

5                                                  5                                                  A

6                                                  6                                                  9

7                                                  7                                                  8

8                                                  8                                                  not returned in output array

9                                                  9                                                  not returned in output array

A                                                  A                                                  not returned in output array

B                                                  B                                                  not returned in output array

0 Kudos