This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AFE7903: Need updated docs on afeParameters.c/CAFE

Part Number: AFE7903

The documentation in the latest (2p9) secure repository seems very out of date (for example AFE79xx_C_Library_Overview.pptx). As far as I can tell, and please correct me if I'm wrong, but the afeParameters.c created by CAFE is not at all useful. I can find no method in CAFE for taking this populated struct and actually running through the steps required to initialize the AFE.

In fact, it seems the only way to initialize the AFE is to dump the opaque binary blob and run through afeDeviceBringupFromMem().

If this is true, this is a significant extra burden on developers. I need to dynamically change some of the base configuration parameters, and having to run a python script to generate a binary blob which gets actually executed in a state machine really limits functionality. I either need to pre-generate a few dozen blobs in various "pre-approved" configurations, or reverse engineer the state machine in the blob. Either way is significantly extra resources (memory and deciding before deployment the "approved" configurations) or work (reverse engineering)!

Is there any plan to bring back some sort of afeDeviceBringupFromParameters() or similar, that will run through the steps on a fully populated struct? Or is there some method I'm missing which performs this function?

Thanks!

  • In the first paragraph, I meant to say "...the afeParameters.c created by LATTE is not at all useful"

  • After much investigation of what's actually in the code, rather than believing the docs...

    1) There is no way to initialize a device from afeParameters because the code to do so doesn't exist in CAFE at all.
    2) All the config code exists in LATTE in Python 2 tied to the GUI, FTDI USB, graphical charts, and all the other stuff used for evaluations, but never for deployment.
    3) The source to LATTE is not fully available--for example mDevice.py is part of a frozen Python 2 module (possibly encrypted in a PYZ) embedded in the AFE79xx binary which is critical for all the rest of the python code)
    4) The python & Blob writes to thousands (probably tens of thousands) of totally undocumented registers with descriptive names like "Property_180h_15_0" which do not exist at all in the "AFE79xx Programming User Guide" aka "Register_Set_SBAU337".

    Please tell me if I'm wrong, but that means the AFE79xx series is only usable: (not just for eval, but AT ALL)

    A) With the end-user running TI's tool with a GUI, under Windows
    -or-
    B) With a set of pre-generated blobs output by the GUI by the vendor into 40KB-ish blobs each. Vendors will need to pre-generate and ship on their device 1 for every possible permutation of parameters (# of receivers, # of transmitters, sample rate each RX and TX, lane configuration, NCO count, etc).
    ... and there is no way to ship a simple standalone blob generator to clients.

    Is this all right? Is there no standalone python generator? Is the mDevice.py (and all other frozen code) releasable so I could make my own standalone generator? Is there a more recent version of the register documentation? Is there a version of CAFE which can initialize the device?

    These capabilities seem kind of critical. I obviously can't ask my users to run a TI tool under Windows. I also don't really want to ship megabytes of pre-configured blobs for every config I can think of and store them in firmware.

    Is this what TI expected--that end users will either use LATTE or vendors will just pre-configure dozens or hundreds of permutations? Or am I missing the expected path?