TI-15.4-STACK-GATEWAY-LINUX-SDK: Viewer for nv-simulator.bin

Hi Ryan,

For debug purpose.

I'm porting TI-15.4 SubG collector to MIPS platform and found orphan realignment is not OK, especially when it caused from MIPS platform power recycle.

I found it caused from orphanAddress check stage. It returns invalid and seems come from nv reload...

One more question is: do I need to pay attention to endianness for nv source code porting?

Thanks.

Peter.

Hello Peter,

I don't completely understand the context of the question but endianness is important.  I recommend you look through the TI-15-4-STACK-GATEWAY-LINUX-SDK User's Guide and CoProcessor Interface Guide.

Regards,
Ryan

Hi Ryan,

The reference does not say anything more.

The problem I faced is : it cannot obtain correct device entry number (CSF_NV_DEVICELIST_ENTRIES_ID) when I stop collector and start again . It will reload nv-simulator,bin file but failed in reading version with mismatch. So it returns value 0 after collector restarted.

Now I found one define NVOCMP_HDRLE which is related to endianness. But change it does not solve the problem completely. Therefore, I believe some porting tasks needed.

Question 1: How to interpret nv-simulator.bin, for example each page header. (debug purpose)

Question 2: How to choose NVOCMP_NVPAGES? Why need compaction page? (any comment)

Question 3: What's the max devices can support by this design? Thanks for support.

Peter.

Hi Peter,

Which device and version of SDK are you using?  Please make sure that it matches the version recommended for TI-15.4-STACK-GATEWAY-LINUX-SDK.

https://dev.ti.com/tirex/explore/node?node=AIpEfnGDfOZ6k-P9SF11iA__pTTHBmu__LATEST 
https://dev.ti.com/tirex/explore/node?node=APeHcG.A0wniaym22zAYKw__pTTHBmu__LATEST 

1. I don't think this file can be "interpreted" but I'll ask experts for more insight.

2. This is a definition configurable from the Coprocessor project if not using the pre-built hex image (4 by default).  An explanation of driver operation is provided in nvocmp.c:

This driver implements a non-volatile (NV) memory system that utilizes multi pages
(consecutive) of on-chip Flash memory. After initialization, all pages except one
are ACTIVE and the remaining one page is available for "compaction" when the ACTIVE
pages do not have enough empty space for data write operation. Compaction can occur
'just in time' during a data write operation or 'on demand' by application request.
The compaction process is designed to survive a power cycle before it completes. It
will resume where it was interrupted and complete the process.

3. A maximum of 50 nodes are supported by default (MAX_DEVICE_TABLE_ENTRIES).

Regards,
Ryan

Hi Ryan,

Just quick response for your question. The chip-set is CC1310 and I use SDK_4_10_00_06 now.

I checked SDK_4_20_00_05 last week, especially checking nvocmp.c & nv_linux.c file and header file.

I did not upgrade to 4_20_00_05 after checking release note and source code changes. I do not think it fix any SubG related problem.

Plan to upgrade to 4_20_00_05 later.

Peter.

That's great to hear Peter, can you provide more detail to help assist other users in the future?

Regards,
Ryan