Messages

1

NXP^TM M522XX, KINETIS and i.MX RT / Re: IIC - wake task on write complete

« on: December 30, 2009, 06:09:50 PM »

Yes, I've studied this code I it's obvious that it should work, but it does not. I'm still trying to debug this, will keep you informed.
BTW, will application receive any message or will be just activated?

Andriy

2

NXP^TM M522XX, KINETIS and i.MX RT / IIC - wake task on write complete

« on: December 30, 2009, 05:33:23 PM »

Hi, I'd like to use task activation on IIC write complete - for performing long writes which do not fit in TX buffer and must be performed sequentially.
According to documentation it's possible - just assign task to tIICParameters.Task_to_wake field.
However I cannot make it work - did I miss something?

Thanks in advance,
Andriy

3

NXP^TM M522XX, KINETIS and i.MX RT / Re: USB, GCC and bootloader - SOLVED

« on: August 20, 2009, 09:38:41 AM »

Hi, thanks for the answer. Unfortunately the problem is somewhere else. Currently I've found that:
After first USB interrupt, interrupt vector table is corrupted (?) and next interrupt (?)  go to undef_int() function, and naturally board is reset by watchdog. The most interesting is that it happens only if compiled with start address 0x1000, with start 0x0 (no bootloader) everything works fine.
I realize that this problem is really strange, I write here to share information - maybe someone sometime find it useful. When I find solution, I'll write here.
BTW, is there any way in ISR (undef_int()) get interrupt vector that caused this interrupt?

UPD1: I've checked that this is not spurious interrupt.

UPD2: It's "Illegal instruction" exception.

UPD3: It seems I was "lucky" and "enjoyed" Speculation Address errata. After I changed code in Starup_gnu.s to unconditional

Code: [Select]

    move.l  #0x61,%d0                      /* This is the workaround 1 due to the Internal FLASH Speculation error in the first devices */
    movec   %d0,#0x0c04
everything works. It's possible that original code

Code: [Select]

move.l  #__FLASH,%d0
add.l   #0x61,%d0
movec   %d0,#0x0c04may not work as expected if __FLASH is not 0x0 (in case of bootloader)

4

NXP^TM M522XX, KINETIS and i.MX RT / USB, GCC and bootloader

« on: August 18, 2009, 02:57:01 PM »

Hi, the next problem I have is the following: compiling my USB application (USB code is unchanged bare uTasker) with GCC everything works fine if application is loaded at address 0x00. If I change it to be loaded at 0x1000 (SPI bootloader) application itself works fine but just after USB connect it hangs and system is restarted by watchdog.
I change only linker script from

Code: [Select]

MEMORY
{
  rom (rx) : ORIGIN = 0x0000, LENGTH = 256Kto

Code: [Select]

MEMORY
{
  rom (rx) : ORIGIN = 0x1000, LENGTH = 252KI'm still trying to investigate the problem but maybe you can point me, maybe there is hardcoded address somewhere in USB code...

Thanks in advance,
Andriy Korud

5

NXP^TM M522XX, KINETIS and i.MX RT / Interrupt handler, GCC

« on: August 17, 2009, 04:07:00 PM »

Hi,
I'm setting interrupt handler using uTasker functionality:

Code: [Select]

INTERRUPT_SETUP interrupt_setup;
interrupt_setup.int_type     = PORT_INTERRUPT;   
interrupt_setup.int_priority = (INTERRUPT_LEVEL_3);
interrupt_setup.int_handler  = irq_handler;                           // handling function
interrupt_setup.int_port_bit = 3;                                    // The IRQ input connected
interrupt_setup.int_port_sense = IRQ_RISING_EDGE;                    // Interrupt on this edge
fnConfigureInterrupt((void *)&interrupt_setup);           
code is compilted with GCC. Do I need to add

Code: [Select]

__attribute__((interrupt_handler)) to my handler function?

6

µTasker general / Re: Proper task state for UART reading

« on: June 01, 2009, 11:15:18 AM »

Thanks, and can you please confirm that:

Code: [Select]

{ "app",       fnApplication,  SMALL_QUEUE, (DELAY_LIMIT)(0.1 * SEC), 0, UTASKER_STOP},task will be invoked in 0.1s by uTasker (single shot)

Code: [Select]

{ "maintenace",fnTaskDebug,    SMALL_QUEUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_ACTIVATE},task will be invoked immediately by uTasker (single shot)

Code: [Select]

{ "period",    fnTimer,        SMALL_QUEUE, (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},task will not be invoked by uTasker at all util another task send event to it or change state with uTaskerStateChange() call

regards,
Andriy

7

µTasker general / Proper task state for UART reading

« on: May 29, 2009, 03:36:00 PM »

Hi, maybe this is really simple question, but:
what is the proper state for task that only read data from UART? UTASKER_GO or UTASKER_STOP?
The task function looks like

Code: [Select]

if (debug_task_state == STATE_INIT) {
debug_uart_init();
debug_task_state = STATE_RUN;
}
while (fnRead(PortIDInternal, ucInputMessage, HEADER_LENGTH)) {
fnRead(PortIDInternal, ucInputMessage, ucInputMessage[MSG_CONTENT_LENGTH]); // flush any unexpected messages (assuming they arrived from another task)
}

if (SerialPortID != 0 && (uart_rx_len = fnMsgs(SerialPortID))) {
while ((uart_rx_len = fnRead(SerialPortID, ucInputMessage, MEDIUM_MESSAGE)) != 0) {
console_cmd_receive((char*)ucInputMessage, uart_rx_len);
}
}
I'm not sure if data on UART will activate and schedule the task.

8

NXP^TM M522XX, KINETIS and i.MX RT / Re: MCF52223 SPI: hangs on register access

« on: December 17, 2008, 06:43:37 PM »

Thanks Mark,
as usual you are right - that helped. I've not defined SPI_FILE_SYSTEM as I have my own device and need to find how to make your SPI code (I'm going to use SPI flash) with my own.

Thanks,
Andriy

9

NXP^TM M522XX, KINETIS and i.MX RT / MCF52223 SPI: hangs on register access

« on: December 17, 2008, 06:18:20 PM »

Hi,
I've just noticed that my MCF52223 hangs on any (read or write) access to QSPI registers (i.e. QMR, QAR). Compiled with CW7.1. Even tried access via *(IPSBAR + 0x340) - the same effect - immediate hang.
Any ideas anybody?

regards,
Andriy

P.S. I've even checked part type via CIR register - it's actually 52223, so SPI should be there. (Some times ago Freescale send us chips with wrong silicon inside).

P.P.S. But I can access (and read correct default values) that register with BDM ("Hardware diagnostics") in CW.
For example:

Code: [Select]

Read  0x0104 at address: 0x40000340
Read  0x0404 at address: 0x40000344And compiler-generated instruction also look ok:

Code: [Select]

movew 40000340 <___IPSBAR+0x340>,%d0

10

NXP^TM M522XX, KINETIS and i.MX RT / Re: MCF52223 - phantom PORT TD?

« on: December 16, 2008, 09:24:23 AM »

Hi Andrij

So you are using the M52223 now;-)

Thanks for the explanation.
Yes, we're starting next project without networking but with USB. So M52223 (and uTasker SP8 of course) is the best solution for us.
Previous M52233-based project is already in production.

Regards,
Andriy

11

NXP^TM M522XX, KINETIS and i.MX RT / MCF52223 - phantom PORT TD?

« on: December 15, 2008, 04:32:58 PM »

Hi,
does anybody know anything about this phantom port? In GPIO description in chapter 12.1 of RM there is port TD and pins PTD[1-3], uTasker also has defines:

Code: [Select]

#define PTDPAR      *(unsigned char *)(PORT_MODULE_ADD + 0x70)    // bur that's all. No information in chapter 12.5.1 Ports Memory Map, no in pinout. I'm really confused.

Best regards,
Andriy Korud

12

NXP^TM M522XX, KINETIS and i.MX RT / Re: Dot-matrix LCD: interface and GUI

« on: December 03, 2008, 09:00:58 AM »

Which Driver chip are you using? I have generic C code for a Toshiba T6963 if that is any help

Cheers

Martin Honeywill

Thanks, we're still selecting, but it looks like that in case of 128x128 size it will be T6963 for sure, for smaller size - also probably, however simple Samsung is more popular for 64x128.

13

NXP^TM M522XX, KINETIS and i.MX RT / Dot-matrix LCD: interface and GUI

« on: December 01, 2008, 09:19:45 PM »

Hi,
does anybody have an experience with implementing simple GUI on dot-matrix LCD (128x64 or 128x128) with common-used 8-bit parallel interface? Any tips, sample code, functions for drawing graphics primitives and fonts would be appreciated.

Best regards,
Andriy Korud

14

µTasker general / No responce from ARP

« on: November 25, 2008, 12:28:02 PM »

Hi,
during long time I've observing strange situation: randomly you have no response from ARP. What I mean - initiating UDP communication (either TFTP of raw) from the device - neither frame is sent, no ARP_RESOLVED or ARP_RESOLUTION_FAILED event is received. Just nothing happens.
The problem is that it happens randomly and I have no idea how, what and where check or debug.
Any ideas?

Best regards,
Andriy Korud

15

NXP^TM M522XX, KINETIS and i.MX RT / Re: GCC 4.2 vs CW 6.3

« on: October 17, 2008, 12:42:35 PM »

BTW, adding -fomit-frame-pointer gcc option reduces code size by ~1k (for my project) without visible side-effects.