Some issues with the K60 V15 beta

[Predielis]

Hi, testing the V15 beta software with CodeWarrior.

It seems I can't have a periodic call of the PIT handler function. It is executed only once.
Am I missing something?

This is the configuration I use:

void fnConfigurePIT(void)
{
   PIT_SETUP pit_setup; // interrupt configuration parameters
   pit_setup.int_type = PIT_INTERRUPT;
   pit_setup.int_handler = RTHandler3; // test a periodic timer
   pit_setup.int_priority = PIT1_INTERRUPT_PRIORITY;
   pit_setup.count_delay = PIT_US_DELAY(1000); // 3245us delay
   pit_setup.mode = PIT_PERIODIC; // periodic interrupt
   pit_setup.ucPIT = 1; // use PIT1
   fnConfigureInterrupt((void *)&pit_setup); // enter interrupt for PIT1 test
}

Also the Windows 7 64 FTP client does not work when uploading the demo web server pages. A Linux client does the job, don't know why.

I am not so sure about this, maybe it is just an Eclipse glitch. The app_hw_kinetis.h is highlited like TWR_K60N512 and KINETIS_K60 are not defined. But this was done in config.h

Regards

[mark]

Hi

I just tried this on a K60F120M board (in tower kit) after changing the code in ADC_Timers.c to support the K60 as follows:

// PIT configuration
//
static void fnConfigurePIT(void)
{
    PIT_SETUP pit_setup;                                                 // interrupt configuration parameters
    CONFIG_TEST_OUTPUT();
    pit_setup.int_type = PIT_INTERRUPT;
    #if defined TEST_PIT_SINGLE_SHOT
    pit_setup.int_handler = test_timer_int;                              // test a single shot timer
    pit_setup.int_priority = PIT1_INTERRUPT_PRIORITY;
    pit_setup.count_delay = PIT_US_DELAY(3245);                          // 3245us delay
    pit_setup.mode = PIT_SINGLE_SHOT;                                    // one-shot interrupt
    #elif defined TEST_PIT_PERIODIC && defined _KINETIS                  // {10}
    pit_setup.int_handler = test_nmi;                                    // not NMI when used by kinetis demo
    pit_setup.int_priority = PIT0_INTERRUPT_PRIORITY;
    pit_setup.count_delay = PIT_US_DELAY(500);                           // 500us perid
    pit_setup.mode = PIT_PERIODIC;
    #elif defined TEST_PIT_PERIODIC
    PORTTC |= (PORT_TC_BIT1 | PORT_TC_BIT2);
    DDRTC |= (PORT_TC_BIT1 | PORT_TC_BIT2);
    pit_setup.int_handler = test_nmi;
    pit_setup.int_priority = (INTERRUPT_LEVEL_7 | INTERRUPT_PRIORITY_5); // NMI to give a high resolution 50us interrupt (the interrupt may not use operating system calls!)
    pit_setup.count_delay = PIT_US_DELAY(50);                            // 50us period
    pit_setup.mode = PIT_PERIODIC;
    #endif
    #ifdef SUPPORT_PITS                                                  // multiple PITS
    pit_setup.ucPIT = 1;                                                 // use PIT1
    #endif
    fnConfigureInterrupt((void *)&pit_setup);                            // enter interrupt for PIT1 test
}

The interrupt handler toggles the second (yellow) LED on the board at 500us.
This worked as expected with the periodic interrupt always arriving and not single shot.

Could it be that the handler in your case is stopping the PIT? Or is it possible that some other code in your project is using the same PIT after you have started it with your call and this setting it to single-shot mode?

I haven't heard fo difficulties with FTP client on Windows 7 64 bit. Could you send a WireShark recording so that the reason for the problem can maybe be seen?

Eclipse does code highlighting based on used and unused (defined) regions. Also VisualStudio 2010 does this.
As far as I have seen both make mistakes and so can not always be trusted. I tend to set a break point in the code and see what happens when it is stepped - invariably the code steps quite happily through the area which the editors have greyed out since it is supposedly "not included". I suppose this editor feature is more complicated than it first looks...

Regards

Mark

[Predielis]

This is the Wireshark dump.
I made some more tests and uTasker is OK. In fact another Win7 64 PC works fine with it.
The defective Win 7 FTP client hangs even with another Linux FTP server. I disabled antivirus, firewalls, etc. but still no joy.
For now I will not investigate any longer, it is strange because everything else seems to be working properly in this PC, but who knows.

Thank you, I will look later in the PIT issue.

[mark]

Hi

The Wireshark recording shows the PC connecting to the FTP server and then requesting a directory listing.
It requests that the server sends the listing to its IP address on TCP port 50578.
The server tries to connect to this port but never gets a connection response.

This means that the TCP socket which the FTP client has prepared for the data connection is not operating correctly. It could be due to a Firewall not allowing connections on this port number.

You could try setting passive mode since it is presently trying in active mode. In passive mode the FTP client will establish the data connection instead, which is probably easier for Firewall settings to work with.

Regards

Mark

[Predielis]

I did some more tests for the FTP problem, but without any luck. Windows firewall and the antivirus are disabled, AFAIK. I gave a try with Filezilla, using passive mode, with no results. I'm not really interested in this thing, it is certainly this notebook's fault.

PIT issue:
I tested your code and it does the same as mine, eg. the test_nmi function is executed only once.
I experimented with other PITs (0,2,3), same thing.
When I reconfigure the PIT every time , putting a fnConfigurePIT() call in the handler, it works as it should, periodically.
This thing is not easy to debug since I'm not able to place breakpoints in kinetis.c. Well, I place them but I only get a blue dot without the check mark which appears in breakpoints elsewhere.

From an Eclipse FAQ:
What does the checkmark next to the breakpoint represent?
The checkmark next to a breakpoint indicates that the debugger has resolved the
breakpoint and will be hit by the debugger. If the breakpoint does not have a checkmark,
the debugger will not hit it.

Not very helpfull.

Thanks again.

[Predielis]

It seems  IP_TX_CHECKSUM_OFFLOAD and IP_TX_PAYLOAD_CHECKSUM_OFFLOAD are not working with UDP.
When set, I see with Wireshark the packets arriving, but are not received by netcat -u -l 9999, as an example.
Things are OK undefining the offload options.
I was thinking that the ethernet controller would be dropping the wrong checkum packets and so Wireshark would not show anything, but this is not the case.

[mark]

Hi

You are absolutely right about UDP and checksum offloading.

UDP frames are being sent with 0xffff in the checksum place due to the fact that the UDP code is still calculating the value, whereby the Kinetis needs it to be 0x0000 otherwise it also uses this for its input and so generates the wrong value.

To correct this the following block in fnSendUDP() in UDP.c can be put into a define region:

Code: [Select]

#if !defined IP_TX_CHECKSUM_OFFLOAD && !defined _WINDOWS                 // {3}
    if (ptrUDP->ucOptions & UDP_OPT_SEND_CS) {                           // calculate checksum if needed   
        unsigned char  ucTemp[2];
        unsigned short usCheckSum = 0;

        usCheckSum = fnCalcIP_CS(0, &network.ucOurIP[0], IPV4_LENGTH);   // do it firstly to IP pseudo header
        usCheckSum = fnCalcIP_CS(usCheckSum, dest_IP, IPV4_LENGTH);
        usCheckSum = fnCalcIP_CS(usCheckSum, (unsigned char *)ucIP_UDP_TYPE, sizeof(ucIP_UDP_TYPE));
        ucTemp[0] = (unsigned char)((usDataLen)>>8);
        ucTemp[1] = (unsigned char)(usDataLen);
        usCheckSum = fnCalcIP_CS(usCheckSum, ucTemp, sizeof(usDataLen));   
   
        if ((usCheckSum = ~fnCalcIP_CS(usCheckSum, ptrData, usDataLen)) == 0) {
            usCheckSum = 0xffff;                                         // avoid zero as checksum since this signifies no check sum, it is equivalent to 0x0000
        }

        ptrBuf--;
        *ptrBuf++ = (unsigned char)(usCheckSum >> 8);                    // save checksum in correct place
        *ptrBuf   = (unsigned char)(usCheckSum);   
    }
#endif
After this, UDP worked correctly on a tested K60.

I also found that there is some IPV6 code that still inserts a checksum so I also made this condition. Since IPV6 is not used much yet I won't show the changes here (there were a couple of changes and also I made the CS calculation conditional so that it was not always included in the code). Once I have tested this fully on the Kinetis it will be included in the next release.

Regards

Mark

[Predielis]

OK, thanks.
I'm having problems with CAN. I set the RX filter at 0, so every ID should be received.
But the message gets through only if the incoming ID exactly matches the RX ID.

This is my configuration of the standard application, the interface used is 1 and I'm using standard IDs.


static void fnInitCANInterface(void)                                     // {1}
{
    CANTABLE tCANParameters;                                             // table for passing information to driver

    tCANParameters.Task_to_wake = OWN_TASK;                              // wake us on buffer events
    tCANParameters.Channel = 0;                                          // CAN0 interface
  //tCANParameters.ulSpeed = 1000000;                                    // 1 Meg speed
    tCANParameters.ulSpeed = 500000;                                      // slow speed for test
    #ifdef PARTNER_CAN
    tCANParameters.ulTxID = (CAN_EXTENDED_ID | 0x00000105);              // our partner's ID on the bus (extended)
    tCANParameters.ulRxID = 0x107;                                       // our standard rx ID on the bus (not extended)
    tCANParameters.ulRxIDMask = 0;                       // use all standard bits for compare
    #else
    tCANParameters.ulTxID = 0x108;                                       // default ID of destination (not extended)
    tCANParameters.ulRxID = (CAN_EXTENDED_ID | 0x00000105);              // our ID (extended)
    tCANParameters.ulRxIDMask = 0;
    #endif
                                                                         // use all bits for compare
    tCANParameters.usMode = 0;                                           // use normal mode
    tCANParameters.ucTxBuffers = 2;                                      // assign two tx buffers for use
    tCANParameters.ucRxBuffers = 3;                                      // assign three rx buffers for use
    CAN_interface_ID0 = fnOpen(TYPE_CAN, FOR_I_O, &tCANParameters);      // open interface

    #if NUMBER_OF_CAN_INTERFACES > 1                                     // {3}
    tCANParameters.Channel = 1;                                          // CAN1 interface
 
    tCANParameters.ulTxID = (0x00000105);              // our partner's ID on the bus (extended)
    tCANParameters.ulRxID = 0x100;                                       // our standard rx ID on the bus (not extended)
    tCANParameters.ulRxIDMask = 0;                       // no filters
        #endif
    CAN_interface_ID1 = fnOpen(TYPE_CAN, FOR_I_O, &tCANParameters);      // open interface
    #endif
}

[Predielis]

Now it seems to be working as it should, and AFAIK I didn't change anything. But I'm probably missing something and uTasker is OK.

Sorry for the inconvenience, I'll do more tests.