Session Object

NSDSP Session objects are used for communication with NSDSP programmer. There are various types of Session objects.

Type

typedef struct nsdsp_session *nsdsp_session_t;

nsdsp_session_t is an opaque reference to an NSDSP Session object. It is passed to all functions dealing with Session objects.

Creation and Destruction

The Session objects are created and destroyed by NSDSP object. To start a session use nsdsp_start_spi_session, nsdsp_start_uart_session, nsdsp_start_prog_session, and nsdsp_start_debug_session functions.

When the Session object is no longer needed, it must be destroyed using nsdsp_end_session function.

The Session objects are linked to the NSDSP object throughout their life. If NSDSP object is destroyed, the Session object is destroyed as well.

An NSDSP object may have only one Session object linked to it. If you try to create a second Session object, the operation will fail.

Session Types

Currently there are five different Session object types - idle, program, debug, SPI, and UART. Some of the functions can be used on sessions of any type, others requires a certain session type. The type of the Session may change - for example when you program a chip for debugging, the session changes its type from programming to debugging. You can detect the current session type with nsdsp_session_get_type function.

Functions that work with all sessions

nsdsp_session_get_type, nsdsp_session_get_rate, nsdsp_session_get_vdd, and nsdsp_session_get_vpp functions work regardless of the type of the session and provide information about session parameters.

Programming Sessions

Programming sessions are used to run canned algorithms for erasing, programming, verifying, and reading target devices. The canned algorithms are invoked with nsdsp_session_erase, nsdsp_session_program, nsdsp_session_program_for_debug, nsdsp_session_verify, and nsdsp_session_read functions.

You can also use nsdsp_session_check_id and nsdsp_session_get_revision_id to check device id and silicon revision id.

Handling Data

The data flow from the NSDSP programmer is generated by the command queue as explained here. To get some data, you need to put data into the queue, then flush the queue using nsdsp_session_flush, then wait for the queue to be processed using nsdsp_session_check_for_data or nsdsp_session_wait_for_data functions, and finally retrieve data with nsdsp_session_fetch_data or nsdsp_session_fetch_data_nb functions.

The nsdsp_session_set_timeout and nsdsp_session_get_timeout functions control timeouts used while waiting for data.

UART Sessions

UART is different from other communications because the data being received is generated by the UART transmitter independently of the command queue. Therefore, there is no special function to receive data - it arrives by itself. If you do not use flow control, the data may be lost.

UART sending is independent of receiving and can be done with nsdsp_session_send_uart function.

SPI Sessions

You can use nsdsp_session_send_spi and nsdsp_session_receive_spi functions to send and receive data.

The nsdsp_session_set_cke and nsdsp_session_set_smp functions can be used to set SPI parameters.

SPI sessions also allow for pin manipulations with nsdsp_session_set_mclr nsdsp_session_set_hvp nsdsp_session_set_pgm nsdsp_session_set_pgcd nsdsp_session_set_red_led nsdsp_session_set_green_led functions.

The nsdsp_session_short_delay, nsdsp_session_delay_us, and nsdsp_session_delay_ms functions can be used to produce various delays.

Debugging Sessions

Debugging sessions are used for debugging and are described here