How to control UPP peripheral channels independantly

Chandra,

The uPP driver on the wiki only supports channel creation using the IOM_INOUT mode, but the uPP channels are still independently programmable.  Calls to GIO_read() or GIO_write() must include a transfer handle.  The struct pointed to by this handle specifies which uPP channel will execute the transfer.  This allows you to manage both uPP channels using a single GIO handle.

Alternatively, you can also use the uPP driver included in the BIOS PSP for C6748, which can be downloaded from this page:

• http://software-dl.ti.com/dsps/dsps_public_sw/psp/BIOSPSP/index.html

The PSP driver allows you to create separate SIO handles for each uPP channel, which may be more intuitive.

Hope this helps.

Hi Joe,

Thanks for reply. I have some doubts which I would like to clarified from you,

1) Related to uPP driver on the wiki : Consider the scenario where two tasks are running with different priority. Let us assume low priority task has executed GIO_write and waiting for Transmit EOL callback at the same time if I got interrupt/event to Receive data on upp channel and scheduled high priority thread to execute GIO_read which will configure DMA for Rx channel. Whether this condition can create UPP peripheral to reset or data corruption on Tx Channel.

2) Whether BIOSPSP driver will work with GIO calls. Because example are given with SIO and user document described with GIO.

3) Unable to run uppSample example of BIOSPSP. It compiles but hangs during loading. It never goes to main().

Thanks,

Chandra

Chandra,

Here are my answers to your questions:

1. The drivers should be thread safe and re-entrant.  If you look at the source code, you should see HWI_disable() and HWI_restore() calls protecting critical actions, such as programming uPP transfers.
2. I have not personally verified that GIO APIs work properly with the PSP driver.  If the documentation says that GIO is supported, then it should work. :)
3. If a BIOS application does not reach main(), that generally means that some error has occurred during system initialization.  Some common problems include: using the wrong GEL file (i.e. some software expects the PSC and pinmux settings to be applied before the application is run), incorrect system setup in the TCF or TCI files, or memory map issues (ex. heap/stack too small).

Hope this helps.

Hi Joe,

I am able to add BIOSPSP upp driver to my application & able to load it also. But when first time I am calling  GIO_read to Receive data on RX Channel, code gets hang and I am able to see Following in Debug console

Thread[main](Suspended)-> _PWRM_F_idleStopClk() at _pwrm_idleGemInclude64P.s64P:37 

Same is the case of BIOSPSP sample also but it gets stuck before main.

Regards,

Chandra

Hi Chandra,

The BIOS PSP 01_30_01 you are referring to, provides 2 sample applications - upp and uppEvm (Placed in : pspdrivers_01_30_01\packages\ti\pspiom\examples\evm6748)

upp - Demonstrates the usage of upp in Loopback mode. whereas,

uppEvm - Demonstrates the usage of upp driver in the duplex mode 0 of operation (for this you need to connect two EVM's. Run uppEvmA on one EVM and  uppEvmB on other EVM ) Please refer section 18.12 of C6748_BIOSPSP_Userguide.

Which sample application are you using?. If it is the first one, the application should run in one go. If it is the second one well, the uppEvmA application hangs until it receives data from the uppEvmB. Load and run the default binaries that come with BIOS PSP first - this confirms all is good with the hardware/setup. Then you can proceed with own modifications and build.

GIO_read(...) is a blocking call and it hangs forever provided no 'timeout' is set.

chandrashekhar mishra

I want to keep read and write operations to these channels independant of each other. I am unable to get handle using GIO_create with IOM_INPUT/IOM_OUTPUT parameter. It works only with IOM_INOUT

If you refer the upp or uppEvm sample application, read and write operations are created/work independant of each other - using SIO calls. Please refer BIOS Userguide for more details on this.

 Hope this helps..

Thanks & regards,

Raghavendra   

Hi Raghwendra,

I am trying to run upp Loopback mode for single evm. This itself I am unable to run because code gets stuck at

Thread[main](Suspended)-> _PWRM_F_idleStopClk() at _pwrm_idleGemInclude64P.s64P:37 

even before reaching to main(). I am able to run  PSP examples for other peripherals with same setup (EVM Board and gel file). I also disabled V/F Scaling support  of Power Manager properties which required for all BIOSPSP example to work.

Regards,

Chandra

Hi Chandra,

Did you try with the default binaries?. If not, please try it.

Would it be possible to share your project? It can speed up the debugging. Also, please list all the tool versions you are using..

Thanks & regards,

Raghavendra

Hi Raghavendra,

I tried pre-compiled upp sample binary to run and it is loading the .out file but I could not see LOG_printf messages as I am getting error message that XDC path /XDC tool is not set. Even though I can see it in preferences window. I attached the snapshot of error message

Also I am using  following tools

CCS Version 4.2.4.00033

 Code Generation tool: TI v 7.2.3

DSP/BIOS: 5.41.10.36

PSP version:pspdrivers_01_30_01

I could not load even after recompiling the same upp sample example provided with psp driver

Regards,

Chandra Shekhar Mishra

Hi Chandra,

chandrashekhar mishra

I tried pre-compiled upp sample binary to run and it is loading the .out file

So, by loading the default binaries you did not face any issues. Probably there is something wrong in the build setup or application.

The LOG_printf messages cannot be viewed in CCSv4 console. You can view it in CCSv3.3. But not to worry, you can even verify in CCSv4 by placing a breakpoint in the application. If you open uppSample_io.c file, line - 387 "LOG_printf(&trace,"Sample Application completed...");" Place a breakpoint at this point and run the application. Hitting this point would confirm working of the sample application.

Coming to the tools,I request you to install all the tools mentioned in the C6748_BIOSPSP_Userguide - section: 1.2.1,build driver and application and then test.

Have you done any modifications to the upp.pjt and uppSample.pjt files?. If so, please let us know the changes made.

Thanks & regards,

Raghavendra

Hi,

I'm experimenting with the PSP uPP driver and am now very confused.  is the uPP GIO interface synchronous or asynchronous?

Several documents refer to GIO as a synronous interface, but from the UPP Device Driver Design document (page28):

The UPP IOM driver supports only asynchronous IO mechanism. In Asynchronous IO
mechanism multiple IO requests can be submitted by the application thread without
causing it to block while waiting for the IO request to complete. Application can
submit multiple I/O requests using the “GIO_read ()” or “GIO_write ()” (also SIO)
APIs and specify a callback function to be called after the IO transfer is completed.

This reads to me that the GIO interface into UPP is asyncronous and uses callbacks.

Also, both examples of UPP in the PSP only provide examples of using the SIO interface to UPP.  it is very difficult to use the GIO interface with no example code to reference

Also, the BIOS PSP User Guide, in the section which describes the UPP driver only discusses the GIO interface but not the SIO interface. Does this mean that GIO is the preferred interface and if so, why do the examples solely use the SIO interface?  If SIO is the preferred interface why does the user guide only discuss the GIO interface?

Hi Jacob,

I assume you are using the BIOS PSP 01.30.01

Sorry for all the confusion made.

UPP can be operated in asynchronous/synchronous IO mechanism depending on the BIOS APIs being used in the application.

• GIO_write()/GIO_read() will be used for synchronous mode of operation.
• ‘GIO_submit() with an appropriate callback’ or ‘SIO_issue()/SIO_reclaim() pair’ will be used for asynchronous mode of operation.

Note: Refer DSP/BIOS userguide for GIO and SIO APIs.

The UPP application provided in the PSP 1.30.01 will make use of ‘SIO_issue()/SIO_reclaim() pair’, which will demonstrate the usage of UPP driver asynchronously.

Best Regards,

Raghavendra

The GIO_write/GIO_read issue seems to be the source of my confusion.  Why does the userguide for the UPP  API's only  refer to the (supposedly synchronous) GIO_read/write calls if according to the same user-guide, synchronous calls are not supported (see quote from previous post)? this reads as if the normally synchronous GIO_read/write calls can be used asycronously and makes no mention of GIO_submit anywhere.  

P.S. I am indeed using PSP 1.30.01

I've tried using GIO_submit and do see a few registers in the upp address space change, but i never seem to enter my upp_rx (configured via UppChanParams).  I have my upp configured as:

uppParams = Upp_PARAMS;
uppParams.devMode = Upp_DevMode_DUPLEX_1;
uppParams.dlbMode = Upp_Loopback_ENABLE_AB;
uppParams.emulationMode = Upp_EmuMode_SOFT_STOP;
uppParams.pllDomain = Upp_pllDomain_0;
uppParams.pscPwrmEnable = FALSE;

With the following channel parameters:

Upp_ChanParams uppChanparamA =
{
TRUE,
Upp_ChanSel_A,
Upp_bitWidth_8,
Upp_dataRate_SINGLE,
Upp_ChanMode_NORMAL,
Upp_dataPackFmt_RJZE,
10000000,
0xFFFF,
NULL,
NULL,
NULL,
NULL,
Upp_fifoThreshold_64,
{
TRUE,
Upp_polarity_ACTIVE_HIGH,
TRUE,
Upp_polarity_ACTIVE_HIGH,
TRUE,
Upp_polarity_ACTIVE_HIGH,
Upp_clkPol_RISING_EDGE_SYNC,
Upp_PinIdleState_IDLE_VAL,
}
};

// parameters for channel B
Upp_ChanParams uppChanparamB =
{
TRUE,
Upp_ChanSel_B,
Upp_bitWidth_8,
Upp_dataRate_SINGLE,
Upp_ChanMode_NORMAL,
Upp_dataPackFmt_RJZE,
10000000,
0xFFFF,
uppReadCallback,
NULL,
uppReadCallback,
NULL,
Upp_fifoThreshold_64,
{
TRUE,
Upp_polarity_ACTIVE_HIGH,
TRUE,
Upp_polarity_ACTIVE_HIGH,
TRUE,
Upp_polarity_ACTIVE_HIGH,
Upp_clkPol_RISING_EDGE_SYNC,
Upp_PinIdleState_IDLE_VAL,
}
};

and creating my gio handles with : 

GIO_Handle* uPPoutputPtr;
GIO_Handle* uPPinputPtr;
*uPPoutputPtr = GIO_create("/Upp0", IOM_OUTPUT, &status, &uppChanparamA, NULL);
*uPPinputPtr = GIO_create("/Upp0", IOM_INPUT , &status, &uppChanparamB, NULL);

Hi Jacob,

Jacob Leemaster

The GIO_write/GIO_read issue seems to be the source of my confusion.  Why does the userguide for the UPP  API's only  refer to the (supposedly synchronous) GIO_read/write calls if according to the same user-guide, synchronous calls are not supported (see quote from previous post)? this reads as if the normally synchronous GIO_read/write calls can be used asycronously and makes no mention of GIO_submit anywhere.  

I understand your point. The data in the Userguide(w.r.t API's) is not appropriate. Sorry for misleading you.

Please consider my previous post wherein I have provided the right information required. I hope you do not have any queries w.r.t that.

Coming to the application, what exactly is your application scenario?. Looking at the UPP configuration shared, all the settings seems to be fine. Is "upp_rx" a callback function?.

Please test the sample application that comes with the PSP and verify.

Best Regards,

Raghavendra

Yes, meant to refer to upp_rx is actually uppReadCallback() with the following declaration:

void uppReadCallback(Uint32 arg1, Uint32 arg2, Uint32 arg3)

i'm currently just trying to get a basic upp driver working and am currently trying to use the GIO_submit function you described earlier.  since I'm trying to use the GIO_submit, the example code (which only uses SIO interface) isn't too helpful.   

should I just give up on GIO and switch to SIO?  

Hi Jacob,

Before you start using the GIO_submit(...) call in asynchronous mode, please verify if the GIO_submit(...) API in synchronous mode is working first(by not providing the callback function). Just do a ''write'' to the upp channel, and check if it is returning/completing successfully without any errors/hang. This is just to verify if the GIO settings are appropriate. Then you can proceed further by providing the application callback function to monitor its completion. The GIO_submit(...) call in asynchronous mode should be able to work.

Since it is a loopback application, need to send a read request first and then a write.

You can also verify/try by placing a breakpoint in the "uppIntrHandler(...)" function(in Upp.c driver file) to check if any completion interrupts are generated. Also, check if it is hitting the function "uppCompleteCurrentIo" wherein, the function completes the current pending request and then invokes the application registered callback(Line 2151 of Upp.c file).

Jacob Leemaster

should I just give up on GIO and switch to SIO?

Not necessary. The reason I asked to test the sample application(that comes with the PSP) is just to verify the setup.

Best Regards,

Raghavendra