UART Routines

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

The only example code using the peripheral uart is the peripheral uart download example.  And that only reads and writes a single byte at a time.  I see the undocumented routines puart_synchronousRead and puart_synchronousWrite.  Can I start reading data a byte at a time until I determine the incoming message length, and then use this read routine to read the rest of the message?  Or will starting that routine reintialize the receive buffer and miss some bits if they already started?  And does this call return control to the OS until all the data bytes requested are read and placed in the specified buffer?  Same basic question for the write routine.  If I just pass the location of the start of the message buffer and length, will this routine transmit the message on the peripheral uart?

0 Likes
1 Solution
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

> Can I start reading data a byte at a time until I determine the incoming message length, and then use this read routine to read the rest of the message?

Yes, you can. The bytes received are buffered in a HW FIFO, so invoking this function will not* reinitialize the receive. Calling this with a NULL pointer for buffer will dump (parameter) length bytes from the HW FIFO.

> And does this call return control to the OS until all the data bytes requested are read and placed in the specified buffer?

This is a synchronous call and will return from the function only after (parameter) length bytes have been read if length is <= 16. Behavior is undefined if a larger length read is attempted.

> Same basic question for the write routine.  If I just pass the location of the start of the message buffer and length, will this routine transmit the message on the peripheral uart?

Yes, and this is a synchronous call too. Behavior if more than 16 bytes (or less if there are un-transmitted bytes in the FIFO already) are written is undefined. Use P_UART_TX_FIFO_IS_EMPTY() to check if the TX FIFO still has bytes.

* Edit

View solution in original post

29 Replies
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

> Can I start reading data a byte at a time until I determine the incoming message length, and then use this read routine to read the rest of the message?

Yes, you can. The bytes received are buffered in a HW FIFO, so invoking this function will not* reinitialize the receive. Calling this with a NULL pointer for buffer will dump (parameter) length bytes from the HW FIFO.

> And does this call return control to the OS until all the data bytes requested are read and placed in the specified buffer?

This is a synchronous call and will return from the function only after (parameter) length bytes have been read if length is <= 16. Behavior is undefined if a larger length read is attempted.

> Same basic question for the write routine.  If I just pass the location of the start of the message buffer and length, will this routine transmit the message on the peripheral uart?

Yes, and this is a synchronous call too. Behavior if more than 16 bytes (or less if there are un-transmitted bytes in the FIFO already) are written is undefined. Use P_UART_TX_FIFO_IS_EMPTY() to check if the TX FIFO still has bytes.

* Edit

Anonymous
Not applicable

More confusion.  First question about the limit of the puart_synchronousRead and puart_synchronous write commands.  You say that trying to read or write more than 16 characters results in an undefined action.  So why in the world would you declare the length parameter as a UINT32 if it's use is limited to 16 characters?

I am rather confused by your answer.  I would hope (If I had low level control, which I don't) that given the buffer location that we supply with these calls, that on a read, the data is read from the FIFO and moved to buffer requested in the call.  And likewise for the transmit with data being moved from the source buffer to the TX FIFO as needed.  I guess you don't have any DMA controllers on your processor.  Why no indicator of TX FIFO full so I can still push more data into the FIFO?  I have anywhere from 4 to 128 byte messages to send.  It sounds like that is not really achievable with your system.  And when I have figured the length, The following bytes are already in the process of being transmitted, so it sounds like using the read is not usable, as it will reinitialize the receive uart.  And transmitting any more than 16 bytes one has to wait til the FIFO is empty before transmitting more which results in a gap in the transmission.  You guys really didn't support any kind of useful uart functionality, did you?

PS Your mybeacon example appears to have the beacon type and subtype in the wrong Endianess.

0 Likes
Anonymous
Not applicable

Okay, I get it that the two routines above are basically useless, unless your message length is under 16 bytes.  Now what I need to do is transmit a larger message.  You have a macro that tells us if the TX FIFO is empty, but not when the TX FIFO is full.  Wouldn't it be a good idea to have a TX FIFO full check so one can add TX bytes until the FIFO is full and again at the next interrupt?  Does this exist, or can it be checked somehow?

Also how/when is the UART Interrupt Callback function called on the TX end of things?  It is called once per character on the RX side.

0 Likes

You can get register for and handle TX done interrupts in your app. Here is some pseudocode:

#include "puart.h"

void application_puart_tx_done(void);

void application_create(void)

{

    // .... all other app create code

    // Register callback that will handle TX done.

    puart_txCb = application_puart_tx_done;
}

void application_tx_data(UINT8* buffer, UINT32 length)

{

     // Set watermark to 0 (when TX is done).

     // Max watermark level is P_UART_WATER_MARK_TX_LEVEL_HIGHEST ( = 15)

     P_UART_WATER_MARK_TX_LEVEL(0);

    if(P_UART_TX_FIFO_IS_EMPTY())

     {

          // Enqueue at most 16 bytes here.

         

     }

     // buffer remaining bytes and length.

     // Enable the TX interrupt. Callback registered with puart_txCb will be invoked when all bytes

     // have been transmitted.

     P_UART_INT_ENABLE |= P_UART_ISR_TX_FAE_MASK;

}

void application_puart_tx_done(void)

{

     // Clear interrupt state

     P_UART_INT_CLEAR(P_UART_ISR_TX_FAE_MASK);

     // TX FIFO is empty now. So send another at most 16 bytes here if required,

     // set new watermark (if not 0) and re-enable TX interrupt.

}

> Also how/when is the UART Interrupt Callback function called on the TX end of things? It is called once per character on the RX side.

It is called once per character if you set up the RX watermark to 1 which is what the uart_firmware_upgrade sample does. You can always set it to any value up to P_UART_WATER_MARK_RX_LEVEL_HIGHEST.

lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Can I start the transmission from the RX interrupt callback routine, and then let the TX callback routine refresh the buffer when it is empty (if I set the watermark to 15)? Does a watermark of 15 bytes allow 16 bytes to be put in it? And it will then generate a TX callback when the FIFO is empty so I can put another 16 bytes in? I also assume I loop and put a byte at a time in using puart_write(nextbyte). And when I finish putting the last group of bytes (probably less than 15) into the buffer, then I disable the interrupt and the rest of the bytes will be transmitted and message is sent with no more tx interrupts.

0 Likes

> Can I start the transmission from the RX interrupt callback routine

Yes.

> Does a watermark of 15 bytes allow 16 bytes to be put in it?

On the TX side, watermark interrupt will be generated when the watermark is reached from a higher number of bytes in the FIFO (so as the FIFO empties). So if you want to put in 16 bytes, use a watermark of 0, fill up to 16 bytes (with puart_write or puart_synchronousWrite) to transmit and then enable the TX interrupt. This will then generate an interrupt when the FIFO is empty.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Arvinds,

I am trying to test my UART functions. I have nothing connected to the receiver, I am dummying input messages from out of a constant buffer that I process every 100th beacon I send (every 10 seconds). My output does not look like anything that I am trying to send. I also see another clock like signal at something much slower than 115200 baud every cycle also. What in the world is going on? Do I need to enable the TX interrupt if I don’t fill the 16 byte buffer? Or can I just stuff up to 16 characters in and it will automatically transfer them, but without generating an interrupt callback? Are the bits of each character sent in the proper order for a standard UART terminal program to interpret? I see the reflection routine being used in firmware download and wonder why the need to reflect the bit pattern? Do I need to do this? Something is obviously wrong in that I am not seeing the output pattern I expect.

Jay

0 Likes

> I also see another clock like signal at something much slower than 115200 baud every cycle also.  What in the world is going on?

Do you have a scope trace of this?

> Or can I just stuff up to 16 characters in and it will automatically transfer them, but without generating an interrupt callback?

Any time you fill up the TX buffer, it will start to be sent out whether you registered for the TX watermark interrupt or not. The interrupt is just a notification that the watermark was reached. If you set the watermark to 0, then the interrupt will trigger when all bytes have been transmitted. If you set it to 5 then the interrupt will trigger when 5 bytes remain in the TX FIFO, but the TX will still continue until the FIFO is empty. If you set the watermark to n then you must have greater than n bytes in the FIFO or the interrupt won't trigger. If you have n+1 bytes in the FIFO and you set the watermark to n, then you may or may not get the interrupt depending on when you enable the interrupt - if number of bytes in the TX FIFO < n by the time you write to the interrupt enable bit, the interrupt will not trigger.

> Are the bits of each character sent in the proper order for a standard UART terminal program to interpret?

Yes. Are you using the right baud rate on the terminal app? Did you configure the right stop bits (generally 1)? Did you set the right parity (generally none)?

> I see the reflection routine being used in firmware download and wonder why the need to reflect the bit pattern?  Do I need to do this?

This has nothing to do with the way uart transfers data. This is a part of the CRC verification step of the upgrade process.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

So if I understand you correctly, then if I have the watermark set to 0 (16 bytes), then if I put less than 16 bytes into the buffer, then I will not get an TX Interrupt callback, but the characters will be transmitted. This is what I want/expect. Don’t want an interrupt callback unless I have to transmit more than 16 characters. So that should be okay.

Hard to get a printout of the scope trace. It might be my hardware that has the level shifter. Until I can rule that out, not sure what is going on. But my data being transmitted is definitely not what I am trying to send.

Can you tell me anything about why that reflection routine exists and if I need to reflect my data before transmitting.

0 Likes

> So if I understand you correctly, then if I have the watermark set to 0 (16 bytes), then if I put less than 16 bytes into the buffer, then I will not get an TX Interrupt callback, but the characters will be transmitted.

No. If you set the watermark to 0, you will get the interrupt when the FIFO level reaches 0 regardless of how many bytes you put in the FIFO initially. The bytes will start to go out the instant FIFO count is non-zero. Because the processor is orders of magnitude faster than the uart baud rate, you will fill up the TX FIFO faster than the HW can empty it while transferring those bytes over the bus. Which is why you have the option of enabling an interrupt to notify you of some FIFO level being reached as the HW is emptying it.

> Until I can rule that out, not sure what is going on.  But my data being transmitted is definitely not what I am trying to send.

Are you sending out binary data?

> Can you tell me anything about why that reflection routine exists and if I need to reflect my data before transmitting.

This is related to CRC calculation for the FW upgrade process and has nothing to do with uart. You don't need to reflect anything unless your application protocol requires you to, and I suspect it does not. The FW upgrade protocol requires it, not because this is over uart, but because it is the upgrade protocol that Broadcom defined and implemented. Please see ota_firmware_upgrade (SDK 1.1 and above) ot ota_secure_firmware_upgrade (SDK 2.1) and you will see that these use reflection too.

Anonymous
Not applicable

This conversation is getting further off track and convoluted.

Here is what I am doing:

I set the TX watermark for 0 (16 bytes).

If I have don’t have more than 16 bytes to transmit, I don’t enable the TX interrupt.

P_UART_INT_ENABLE |= P_UART_ISR_TX_FAE_MASK; // only executed if I have more than 16 bytes to transmit.

So I don’t expect a TX interrupt, correct? But the data will go out when loaded into the TX FIFO, correct?

If I have more data and need to wait until the FIFO is empty I execute the above to enable the TX Interrupt callback that will send out another buffer of TX data of up to 16 bytes again either enabling the interrupt or not based on if there is still more data to transmit. Should this scheme work?

0 Likes

> I set the TX watermark for 0 (16 bytes)

Sorry, I am confused here. The watermark can be 0, but cannot be 16. But I will go with 0 for now.

> So I don’t expect a TX interrupt, correct?  But the data will go out when loaded into the TX FIFO, correct?... Should this scheme work?

All correct. This will work.

0 Likes
Anonymous
Not applicable

How do I purge the TX Fifo at initialization??? It looks like the call to P_UART_TX_FIFO_IS_EMPTY() is always returning false now.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Arvinds,

I have no idea of what is going on now. I replaced all calls to puart_write to call puart_write(0x48) so I write a “H” character. I searched the codebase for any other calls, but nothing. Also searched for any calls to puart_synchronousWrite and there aren’t any. Yet I am seeing a bunch of garbage data going out on the uart about once every 10 seconds (which should be my transmission rate). I am at a complete loss, what is going on? Where is this crap coming from???? It isn’t my app sending it, but it has to be. How does data get into the tx buffer to start transmitting? And is the initialization correct? How do I debug this? I can’t use HCI trace since that kills my timer interrupt. I have no idea what is happening at the low levels of the uart, nor can I even look if I wanted to. This is like hunting mosquitos with rifle while wearing a blindfold at night.

0 Likes
Anonymous
Not applicable

Okay, my write of a single byte triggers a bunch of Tx characters.  The timing is correct and changes when I change it.  So it is my trigger, but I am now simply trying to output a single "H" character.  But I end up with a bunch of junk characters going out.  Why?  I certainly don't know.  But I am guessing it has to do with the UART initialization and setup.  Somehow calling puart_write with a single character is generating a stream of output.  Perhaps if the TX watermark and interrupt are being used incorrectly.  But since there is no documentation of the peripheral uart APIs and no example with a TX interrupt or multiple TX bytes being sent, I am flying completely blind.

0 Likes

Have you checked the electrical connections? Are the levels correct? I added this to the uart_firmware_upgrade sample app and it works right (I just chose it because it initializes peripheral uart in a way that is known to work). I see the expected sequence of bytes on a terminal app using 115200, no flow control, 1 stop bit, no parity.

//// Global definitions

// Array of bytes to send

UINT8 ascii_array[64] = { 48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,

                                     65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,

                                     82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,

                                     99,100,101,102,103,104,105,106,107,108,109,110,111 };

// TX done callback

static void puart_tx_done_callback(void);

int ws_upgrade_uart_init(BLE_PROFILE_PUART_CFG *puart_cfg, void (*puart_rx_callback)(void*))

{

     ///// All the rest of the init function here.

    /////////// ---> Register the TX done interrupt callback function.

    puart_txCb = puart_tx_done_callback;

    // Enable the CPU level interrupt

    puart_enableInterrupt();

    /* END - puart interrupt */

    return (TRUE);

}

UINT32 bytes_to_print = 0;

UINT32 uart_write_byte_index = 0;

void puart_print_some_bytes(UINT32 num_bytes_to_print)

{

    if(!num_bytes_to_print)

        return;

    bytes_to_print = num_bytes_to_print;

    ble_trace1("Printing bytes: %d", num_bytes_to_print);

    // Set watermark to 0 (when TX is done).

    // Max watermark level is P_UART_WATER_MARK_TX_LEVEL_HIGHEST ( = 15)

    P_UART_WATER_MARK_TX_LEVEL(0);

    if(P_UART_TX_FIFO_IS_EMPTY())

    {

        // Enqueue at most 16 bytes here.

        UINT8 i;

        for(i = 0; i < 16; i++)

        {

            puart_write( ascii_array[(uart_write_byte_index++) & (sizeof(ascii_array) - 1)] );

            bytes_to_print--;

            if(!bytes_to_print)

                break;

        }

    }

    else

    {

        ble_trace0("TX FIFO is not empty");

    }

    // Enable uart interrupt.

    P_UART_INT_ENABLE |= P_UART_ISR_TX_FAE_MASK;

}

void puart_tx_done_callback(void)

{

    P_UART_INT_CLEAR(P_UART_ISR_TX_FAE_MASK);

    // Put more bytes if required.

    if(bytes_to_print)

    {

        UINT8 i;

        P_UART_WATER_MARK_TX_LEVEL(0);

        // Enqueue at most 16 bytes here.

        for(i = 0; i < 16; i++)

        {

            puart_write( ascii_array[(uart_write_byte_index++) & (sizeof(ascii_array) - 1)] );

            bytes_to_print--;

            if(!bytes_to_print)

                break;

        }

        // Enable uart interrupt.

        P_UART_INT_ENABLE |= P_UART_ISR_TX_FAE_MASK;

    }

    else

    {

        ble_trace0("Done printing all bytes");

    }

}

---------------------------------------

In hello_sensor.c, I call puart_print_some_bytes() every 1s.

void hello_sensor_timeout(UINT32 arg)

{

    extern void puart_print_some_bytes(UINT32 n);

    ble_trace1("hello_sensor_timeout:%d\n", hello_sensor_timer_count);

    switch(arg)

    {

        case BLEPROFILE_GENERIC_APP_TIMER:

        {

            hello_sensor_timer_count++;

        }

        break;

    }

    ////////// Print some bytes

    puart_print_some_bytes((hello_sensor_timer_count * 10) % 100);

}

On the terminal app:

0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmno0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklm

This goes on 10, 20, 30, 40, 50, 60, 70, 80, 90, 10 .... bytes/characters at a time forever.

0 Likes
Anonymous
Not applicable

Here is where I am at.

Put yourself in my shoes for 5 minutes.

I have no debug capability in this system. If I turn the trace on my timing falls apart and the app doesn’t work. What does that leave me to work with? Not much. I can watch beacons and see if their timing and parameters are correct. (by the way the type and subtype in your my beacon example app output a beacon with the endianess of those fields backwards). And I can watch the output of the uart I am trying to generate responses on. That’s it. Not a very good way to develop code, is it? I have no clue what is going on in the code. No way to look inside the system. How frustrated would you be trying to use a system with those limitations? And no documentation to boot.

Where I am at now is removing lines of code and calls to see what is causing the burst of spurious data. What I just found is that my routine that is parsing through a dummy receive message (no app on the other side yet), to create a response message is somehow causing this message. It makes no uart API calls. It merely parses the receive buffer and builds a response buffer (but does not send anything) and returns. All I can GUESS at this point is that there is something illegal going on and sending me through a reset that is generating the BS uart message traffic. But how can I tell if that is happening? I can’t. How lovely. Welcome to my nightmare.

I need debug ability for this so I can output to the HCI UART and monitor it for errors and or flow. Is there a way to do this without losing the timer interrupt? How can I determine what is going on in the code from the outside?

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Found the lowest denominator to the spurious data on the uart. Not surprisingly it is a routine that I could never verify if it was working properly. I tried, but without debug could not tell if/what was wrong. I added a checksum byte to verify the readback, and it never seemed to work, but no way to know for sure without debug. I am attempting to write a 113 byte buffer to NVM. The last call to NVMWrite is the culprit on the UART as when I comment it out, I only see single byte transmissions of the same byte every time period. Not the “H” that I am trying to write, but perhaps a reflection (I haven’t checked yet and didn’t I ask about that yesterday?). At least it isn’t sending a bunch of junk. So if you can tell me why this is a problem that would be great.

Master_beacon_table is 112 bytes (plus the added 1 byte checksum for verification).

void SaveBeaconConfig()

{

UINT8 local_buffer[sizeof(master_beacon_table) + 1];

UINT8 i, csum;

memcpy(&local_buffer, &master_beacon_table, sizeof(master_beacon_table));

csum = 0;

for (i = 0; i < sizeof(master_beacon_table); i++)

{

csum += local_buffer;

}

local_buffer = ~(csum) + 1;

bleprofile_WriteNVRAM(0x20, (UINT8)(sizeof(master_beacon_table) + 1), (UINT8 *)&local_buffer);

}

0 Likes

The default stack size is 1024 bytes. One possibility is that you are very close to running out of stack because of that 113 byte local array and when you invoke bleprofile_WriteNVRAM(), you end up clobbering the stack.

> Not the “H” that I am trying to write, but perhaps a reflection (I haven’t checked yet and didn’t I ask about that yesterday?).

Yes, you did, and I answered it too. The uart HW/driver do not reflect any bytes (TX or RX) and the app is not required to reflect any bytes either.

0 Likes
Anonymous
Not applicable

Okay, so you are suggesting I create more global variables for any kind of buffers being used. I can do that. But it would be EXTREMELY helpful if there was actual documentation on all this stuff. It doesn’t say anything anywhere about a 1k stack limit.

0 Likes
Anonymous
Not applicable

Hi Arvinds,

I have some follow up questions on your sample UART TX codes.

>> void puart_tx_done_callback(void)

>> {

>>    P_UART_INT_CLEAR(P_UART_ISR_TX_FAE_MASK);

I want to understand why TX_FAE is cleared here on callback. 'puart_txCb' is from serialized through Task and not directly invoked from ISR. If that is the case, it seems to me that the TX_FAE interrupt should have been cleared by ISR, otherwise the deferring Task that invokes 'puart_txCb' would not have a chance to run.

>>        // Enable uart interrupt.

>>        P_UART_INT_ENABLE |= P_UART_ISR_TX_FAE_MASK;

Why does it keep enable TX_FAE interrupt again? There is no place in your codes that disables TX_FAE.

So, once TX_FAE is enabled by puart_print_some_bytes(), it should remain enabled.



Unless TX_FAE interrupt is being disabled by low level codes before invoking 'puart_txCb', the above part of codes doesn't seem to make sense. Can you provide clarification on this? TX_FAE interrupt is disabled internally by low level ISR before deferring to a Task for invoking 'puart_txCb'?



Thanks in advance!!



0 Likes

The ISR context handler does not clear the interrupt. It only disables the interrupt. Since the thread context handler is responsible for handling the interrupt (the real action that needs to be taken here), the thread context interrupt callback has to clear the interrupt state and re-enable it when required.

Anonymous
Not applicable

Hi Arvinds, Thanks for the quick clarification!!

0 Likes
Anonymous
Not applicable

Still not able to get buffers bigger than 15 bytes to work.  Only the first 15 bytes go out.  Obviously my callback is not working  I think I did what you said, but I am still rather unclear on exactly how the watermark is used.  I am setting it to 15 initially.

I am still very confused on the P_UART_WATER_MARK setup.  Does this tell how many bytes to transmit before generating interrupt callback?  And if so, shouldn't it be setup prior to stuffing the TX FIFO, not after?  No documentation on any of these functions confuses the issues horribly.  Bottom line is my first 15 bytes go out, and then nothing.  Looks like my callback is set up properly, but I get no other bytes transmitted.  What is the problem?

Here is my basic setup:

void App_Create(void)

{

     P_UART_WATER_MARK_TX_LEVEL (15);

     puart_txCb = puart_tx_callback;

}

void App_tx_data(void)

{

     P_UART_WATER_MARK_TX_LEVEL(bytes transmitting this loop);

    if (P_UART_TX_FIFO_IS_EMPTY())

     {

          fill Tx buffer with up to 15 bytes

     }

     P_UART_INT_ENABLE |= P_UART_ISR_TX_FAE_MASK;

}

void puart_tx_callback(void)

{

     P_UART_INT_CLEAR(P_UART_ISR_FAE_MASK);

     if more data to transmit

     {

          P_UART_WATER_MARK_TX_LEVEL(bytes transmitting this loop);

          fill Tx buffer with up to 15 bytes

          P_UART_INT_ENABLE |= P_UART_ISR_TX_FAE_MASK;

     }

}

0 Likes
Anonymous
Not applicable

Perhaps here is a clue:

I had to declare puart_txCb locally in my module.  It would otherwise end up being undefined.  Did you build the above in SDK 1.1.0??? Could this be the problem?  What variable contains the tx callback in SDK 1.1.0?

That could explain why the callback never happens.  I need to set up the callback into your global variable.  When I just tried to set puart_txCb to the callback routine in my init routine, it told me puart_txCb was undefined.  So I had to declare it locally.

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Arvinds,

I did notice a big difference in my program vs your sample. In your sample you set puart_txCb to your callback routine. When I did that in my module, I needed to declare puart_txCb because the linker said it was undefined. I am using SDK 1.1.0. Could this be the problem that puart_txCb is not in SDK 1.1.0? It would explain the lack of callback and no additional characters going out. I hope there is either another variable or a patch for SDK 1.1.0.

Can you please respond and let me know if this is the problem, and then later if you need with a solution.

0 Likes

> I am still very confused on the P_UART_WATER_MARK setup.  Does this tell how many bytes to transmit before

> generating interrupt callback?  And if so, shouldn't it be setup prior to stuffing the TX FIFO, not after?

The watermark is the level (number of bytes remaining in the TX FIFO) at which you want the interrupt to trigger as the HW is emptying it. It is not the number of bytes after which you want the interrupt. If you set the watermark to 0, the interrupt will be triggered when the TX FIFO is emptied (so you can enqueue up to 16 more bytes for transmission). So, you must set it to a value less than the number of bytes you put in the FIFO. In my sample code above, I set the watermark to 0 so the app can be notified that there are no more bytes to transmit. I then enqueue up to 16 more bytes to transmit.

> Did you build the above in SDK 1.1.0??? Could this be the problem?  What variable contains the tx callback in SDK

> 1.1.0?

No. I used SDK 2.x for my sample code. 20732 and SDK 1.1 does not support TX watermark interrupts. This was an enhancement we added to 20736/7 and SDK 2.x.

----   EDIT ----

As a workaround for 20732 based programs using SDK 1.x, you can poll the TX FIFO to check if it is empty in the fine timer callback and then enqueue more bytes if it is.

Anonymous
Not applicable

Just got started on my bcm92073x_le_kit.  I plan on developing a UART interface to my matab signal processing software running on laptop.  It uses a custom fixed format frame to send upt to 8 channels of data from ADC to MATLAB.  I am porting it from TI CC2540 (8051 based processor).  Any helpful hints are appreciated.  Also if I can help in return let me know.

0 Likes
Anonymous
Not applicable

My main problem is the Tx message.  If I need to transmit more than 16 bytes, the callback function doesn't appear to be supported in SDK 1.1.0.  Not good if you are using the 920732 chip.  Other than that, I can probably help you if you have other things you are trying to do.

0 Likes