Messages

1

NXP^TM M522XX, KINETIS and i.MX RT / Re: Which functions are thread-safe?

« on: November 18, 2012, 08:05:24 AM »

Thanks, very clear as always.
I don't think my code ever have the TX interrupting TX behaviour, so why the exception happens is still not clear. It seems TX over RX breaks things.
Anyway the TX inside a task seems to solve the problem.

Regards.

2

NXP^TM M522XX, KINETIS and i.MX RT / Which functions are thread-safe?

« on: November 16, 2012, 10:58:27 AM »

Is it possible to call uMemcpy and fnSendUDP from inside a PIT timer interrupt handler? At the same time I would be receiving through a callback function set up with fnGetUDP_Socket.

From time to time the application stops in the unhandled interrupt function, and it seems that a memory corruption happens inside uMemcpy.
uMemcpy does not seem to be reentrant, when using DMA. I did a quick test disabling and enabling interrupts inside of this function, but I still have crashes. This event is rare, so it's not easy to debug.
fnSendUDP too seems to be risky.

What is the best way to handle this problem?

Thanks.

3

NXP^TM M522XX, KINETIS and i.MX RT / Re: 52235 and Ethernet buffers

« on: October 21, 2012, 09:09:12 PM »

It works, many thanks.

4

NXP^TM M522XX, KINETIS and i.MX RT / Re: 52235 and Ethernet buffers

« on: October 08, 2012, 02:26:36 PM »

From time to time I get back to this old project.
The program crashes when USE_MULTIPLE_BUFFERS is defined and a packet longer than LAN_BUFFER_SIZE is received.
I made a quick fix in fnExtractNextRx(void), but there is certainly a better way.

if (iBuffers*256 < LAN_BUFFER_SIZE - 256)  // line added
              while (iBuffers--) {
                uMemcpy(ptrInputBuffer, ptrRxBd->ptrBD_Data, 256);
                ptrInputBuffer += 256;
                usFrameLength += 256;
#ifdef USE_IP_STATS
                if (ptrRxBd->usBDControl & OVERRUN_FRAME) {
                    fnIncrementEthernetStats(TOTAL_LOST_RX_FRAMES);      // we lost a frame due to RX overrun so count the event
                }

and

if((ptrRxBd->usBDLength - usFrameLength) < 256)  //line added
    uMemcpy(ptrInputBuffer, ptrRxBd->ptrBD_Data, (ptrRxBd->usBDLength - usFrameLength)); 

Regards

5

NXP^TM M522XX, KINETIS and i.MX RT / Re: Some issues with the K60 V15 beta

« on: March 07, 2012, 04:09:22 PM »

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.

6

NXP^TM M522XX, KINETIS and i.MX RT / Re: Some issues with the K60 V15 beta

« on: March 05, 2012, 10:05:45 AM »

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
}

7

NXP^TM M522XX, KINETIS and i.MX RT / Re: Some issues with the K60 V15 beta

« on: March 02, 2012, 10:52:08 AM »

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.

8

NXP^TM M522XX, KINETIS and i.MX RT / Re: Some issues with the K60 V15 beta

« on: February 28, 2012, 06:16:12 PM »

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.

9

NXP^TM M522XX, KINETIS and i.MX RT / Re: Some issues with the K60 V15 beta

« on: February 28, 2012, 10:27:37 AM »

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.

10

NXP^TM M522XX, KINETIS and i.MX RT / Some issues with the K60 V15 beta

« on: February 23, 2012, 04:41:41 PM »

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

11

NXP^TM M522XX, KINETIS and i.MX RT / Re: Codewarrior 10.1 & uTasker v1.4 Build Issues

« on: February 22, 2012, 11:08:09 AM »

'Regenerating dependency file: uTasker/utFAT/mass_storage.d'
' '
'Building file: C:/ECET_590/uTaskerKinetisV1.4-5/uTasker/utFAT/mass_storage.c'
'Invoking: ARM Compiler'
"C:/Program Files/Freescale/CW MCU v10.1/MCU/ARM_Tools/Command_Line_Tools/mwccarm" -gccinc @@"uTasker/utFAT/mass_storage.args" -o "uTasker/utFAT/mass_storage.obj" -c "C:/ECET_590/uTaskerKinetisV1.4-5/uTasker/utFAT/mass_storage.c" -MD -gccdep
### C:/Program Files/Freescale/CW MCU v10.1/MCU/ARM_Tools/Command_Line_Tools/mwccarm Usage Error:
#   Argument(s) expected
#   while parsing option '-I'

Been here too.
Edit Project Properties->C/C++ General->Path and Symbols->Includes->C Source Files
and set the correct path, in my case
C:\Users\Username\workspace\uTaskerKinetisV1.4-15\Applications\uTaskerV1.4

It was a matter of uTaskerKinetisV1.4-15 different from \uTaskerKinetisV1.4

12

NXP^TM M522XX, KINETIS and i.MX RT / Re: Kinetis CW10.1 Linker problem

« on: February 22, 2012, 11:00:17 AM »

Hi

I think that this problem is coming from the location in which the CW10.1 program has been installed.

Open the project properties and go to “C/C++ Build | Settings | ARM Linker | Input” – there is an additional Library link which points to the install directory.

"C:\Program Files\Freescale\CW MCU v10.1\MCU\ARM_EABI_Support\ewl\EWL_Runtime\Runtime_ARM\Mathlib\lib\FP_fixedI_Thumb_LE_v7M.a"

I had this problem. On 64-bit, Codewarrior is installed in C:\Program Files (x86)\Freescale (note the x86).

13

NXP^TM M522XX, KINETIS and i.MX RT / Re: 52235 and Ethernet buffers

« on: February 03, 2012, 11:53:50 AM »

I raised OUR_HEAP_SIZE from 19*1024 to 25*1024,  SIZE_OF_RAM from 32*1024 to 64*1024 but I can't have a single buffer more than with the default parameters.
Anyway USE_MULTIPLE_BUFFERS seems to solve my problem, so for now I'm happy with it.
Of course, if you are interested in this issue and need me to make some more tests, please ask.

Thanks again.

Edit: 52235 only have 32K of RAM, so SIZE_OF_RAM can't be touched. I'll redo my test with a smaller heap increase.
Edit2: set OUR_HEAP_SIZE to 21 but still can't allocate one more buffer.

14

NXP^TM M522XX, KINETIS and i.MX RT / 52235 and Ethernet buffers

« on: February 02, 2012, 10:50:23 AM »

Hello, I'm experimenting with an old M52235EVB board.
It seems my application is dropping UDP packets, so I'm trying to raise NUMBER_OF_RX_BUFFERS_IN_ETHERNET_DEVICE.
It seems it works only if at the same time I reduce LAN_BUFFER_SIZE, it seems that their product should be less than a certain threshold. Eg I can double NUMBER_OF... only if  LAN_BUFFER_SIZE is set to one half.
Is my impression correct? How can I overcome the problem?
uTasker 1.3sp8 with Codewarrior 7.2.

Is this older CPU still worth, or is it better to switch to something newer? I'm seeing the compiler doing nasty errors, even with optimization off.

Thanks.

15

NXP^TM M522XX, KINETIS and i.MX RT / Re: Kinetis demo: needs single stepping to start

« on: April 21, 2011, 05:03:14 PM »

I somehow solved my problem copying the two lines
 UNLOCK_WDOG();                                                   // open a windows to write to watchdog
             
WDOG_STCTRLH = (WDOG_STCTRLH_STNDBYEN | WDOG_STCTRLH_WAITEN | WDOG_STCTRLH_STOPEN | WDOG_STCTRLH_ALLOWUPDATE | WDOG_STCTRLH_CLKSRC); // disable watchdog
 
At the top of the main() function.

Don't know why it works. Remember that the watchdog didn't kick in when I was slow, just the opposite of what is reasonable.

More details next week.

Regards.