Unable to get PSC04 CY8KIT-049-42xx Transmit and Receive bin array, Please Help

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

cross mob
Anonymous
Not applicable

I've got Rx reception only of an array of the 40 bytes, but I cannot Tx the answering array of 60-bytes consistently.

So far I've got the following Rx code to work without Tx'ing,  now get just a few mcu<-->mcu transfers(1 pac reception and one pac Tx'ing) and then pgm locks up while Rx or Tx.

I've been workings on this problem  tens of hours trying to disambiguate the spec sheet to write correct code!

The mostly likely cause of my problems is that I'm not coding handling of the interrupts properly, causing the pgm to hang.

I

My goal:

Receive 40-bytes from a PIC MCU which is a mixture of binary data and cmds. The Cy then processes these bytes and sends back an answering array also of 60 bytes.

The PIC MCU initiates each session every .2-Sec,

The Cy should answer back with Tx'ing 60-bytes immediately after processing the received data, and just once within .2 Sec, then it waits for the next packet of 48 bytes.

I know the PIC is Tx'ing and working perfectly, verified RS232 for proper timing/data on my digital storage scope.

I cannot seem to get the information on how to do this properly from the SCB UART datasheet(SCB Ver. 3.20) it offers many possible options, but almost no guidance on what API's to use and I cannot seem to disambiguate the when, where, how, why or why not to use them.

My confusion is immense,  even though I have been successfully coding MCU's for ten's of years(mostly PIC lately.)

Googled the web and Cy websites, nothing but the most vague and elementary examples, but only way too simple, not well-explained and non-robust code found.

Working for a living as a programmer means that "A word too wise is not sufficient!"

As a result my coding is cut and try coding..I am desperately attempting to hack my code to work!

//-----------------------------

I have SCB  config'd  Tx  and Rx buffer size set to 62 and 41 bytes respectively.

The only interrupt I have selected for TX is UART_DONE.

For receive, only the default Rx FIFO not empty

I am using only internal interrupts and my INT_UART interrupt handler  has the alias UA and handles both Rx and Tx interrupts.

I have initialized and started the UART interrupt handler correctly since it does work intermittently,

//Before main()

CY_ISR_PROTO (ISR_UART); //in prototypes list (doesn't seem to make any difference if it omitted.

static unsigned char Rx[56],  Tx[62], *tp=Tx;

static unsigned int   Pacs;

volatile unsigned char Findit, Sent, HmS5, rbyt, k, erx;

int main()

{

start: //----------------------- start -----------------------

if(newbyte)

  { if(HmS5>4)  //every 5 hundred milliseconds

     { Cy2p();

       Sent=0;  //clear to send next packet to PIC

       HmS5=0;

       led_Write(0);  //lights up active low to indicate pac reception/TX activity

     }

    if((Rx[2]==0xAA)&&(Rx[4]==0xAA)&&(Rx[6]==0xAA)) //redundant check for a correct order of bytes in array received

     { Pacs++;  //diagnostic to count successful full pacs received

     }

    else

     { erx++;   //diagnostic ot count error pacs received

     }

wa:  if(Display!=Ready) goto wa;

     strcpy(bp,"P= ");Value=Pacs;ParseNum();strcat(bp,np);

     if(erx)

      { strcat(bp," E= ");Value=erx;ParseNum();strcat(bp,np);

      }

     FillBuf();Display=Displaying;

     newbyte=0;

  }

    goto start;

void ISR_UART()

{

  int32 source;  //var  holds states of all UA interrupt flags states

                            //When newbyte is set, this ISR handles the TX interrupt, otherwise the Rx

  if(newbyte==1)  .// flag set  indicates a full packet of 48-bytes has been received and pauses reception until reset by main processing.

   { goto HandleTx;

   }

Getit:

  source = UA_GetRxInterruptSource();  // Returns the status of RX interrupt source that caused interrupt event

  // Checkr "RX FIFO not empty" interrupt

if(UA_INTR_RX_NOT_EMPTY & source)

  {

    k = UA_UartGetByte();

    if(rbyt==0)Rx[0]=k;

   // Attempt to Clear UART "RX FIFO not empty interrupt"

   UA_ClearRxInterruptSource(UA_INTR_RX_NOT_EMPTY); //Does not clear if FIFO has more bytes

   if(FindSt==0)

    {

      if( (rbyt==0)&&(k==0xAA) )//possible start of a pac. Pac start bytes are all 0xAA      start bytes are bytes 0,2,4,6 or array received

       { FindSt=1; // found possible start of a stream

         rbyt=1;

         Rx[rbyt]=k;

       }

      else

       { goto StartEr;

       }

    }

   if(FindSt)

     { if( (rbyt==2)||(rbyt==4)||(rbyt==6) )  //using the first four even bytes set always to 0xAA to detect correct start of a Rx or Tx stream.

        { if(k != 0xAA) goto StartEr;           //bad start detected

        }

     }

   if(rbyt)    //stream has started to being received

    { Rx[rbyt]=k;

      rbyt++;

      if(rbyt<40)  //40 bytes for now is expected from PIC

       { goto Getit;  //check for any more bytes in FIFO

       }

      else //assume a pac of 40 bytes 0-39 has been received

       {

         FindSt=0;

         rbyt=0;

        newbyte=1;

         goto Clrit;

         led_Write(1);

       }

    }

   else

    {

StartEr:

     rbyt=0;

     FindSt=0;

     goto Getit;

    }

  }

HandleTx:

if(Sent==1) //Flag indicating that a packet has started/finished sending a packet of bytes to PIC by a call to Cy2p()

  { source = UA_GetTxInterruptSource();

   if(UA_INTR_TX_UART_DONE & source)

      {  UA_ClearTxInterruptSource(UA_INTR_TX_UART_DONE); //Does not clear if FIFO has more bytes

         UA_ClearPendingInt();

      }

  }

Clrit:;

   //UA_ClearPendingInt();

   UA_rx_ClearInterrupt();

}

//Tx data setup routine

void Cy2p()

{ // code not shown updating  values of Tx[ ] array of 60 bytes, then

if(Sent==0)  //A received pac received, now Cy answers:

  {

          UA_SpiUartClearTxBuffer();

          UA_SpiUartPutArray(tp,60u);

          Sent=1;

          HmS5=0;

  }

}

0 Likes
1 Solution
Anonymous
Not applicable

I have realized that if i cannot find the information needed for deterministic programming of the SCB UART, then I must conclude that I been  engaging in "Voodoo" coding that cannot be relied upon. I am not working on a toy.

Having tens of hours unsuccessfully  trying to write code by trail and error, generating code that doesn't work because I cannot understand or encounter only vague documentation, I have come to the conclusion I am foolishly  writing code I cannot explain(even to myself)  because of lack of any solid documentation on exactly how PSOC SCB  API interrupts work,

Therefore, I have chosen to abandon use of the SCB UART completey.

Instead, I have I coded my own  serial link, using  two pins for bidirectional Clock and Data lines and I've got it to work perfect.  I've coded this type of thing before, and  was able to adapt existing code I've written.

I was able to modify my archived code to get it mcu<-->mcu communication to work perfectly, and was able to do this and test its robustness for handling HW/SW errors in < 6 hrs.

View solution in original post

0 Likes
2 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

Can you please post your complete project or a shortened version that shows the error so that we all can have a look at all of your settings. To do so, use

Creator->File->Create Workspace Bundle (minimal)

and attach the resulting file.

Bob

0 Likes
Anonymous
Not applicable

I have realized that if i cannot find the information needed for deterministic programming of the SCB UART, then I must conclude that I been  engaging in "Voodoo" coding that cannot be relied upon. I am not working on a toy.

Having tens of hours unsuccessfully  trying to write code by trail and error, generating code that doesn't work because I cannot understand or encounter only vague documentation, I have come to the conclusion I am foolishly  writing code I cannot explain(even to myself)  because of lack of any solid documentation on exactly how PSOC SCB  API interrupts work,

Therefore, I have chosen to abandon use of the SCB UART completey.

Instead, I have I coded my own  serial link, using  two pins for bidirectional Clock and Data lines and I've got it to work perfect.  I've coded this type of thing before, and  was able to adapt existing code I've written.

I was able to modify my archived code to get it mcu<-->mcu communication to work perfectly, and was able to do this and test its robustness for handling HW/SW errors in < 6 hrs.

0 Likes