Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - ewan

Pages: 1 [2] 3
16
If I drag and drop using FTP the file appears to arrive intact and with its own name. I then refresh the FTP window and the file reverts to F.BIN with the smaller size.

17
It is all wrong. How do I ensure the SPI is really blank? So far, the file is in the memory chip. It has the name "F.BIN" and is 33kBytes in size. The file "H_Upload.bin" is 70kBytes in size so it looks as though the upload is really bad. The files in the chip are:-

0.HTM to 8.HTM, A.HTM, B.GIF then  F.BIN.

Thanks,
Ewan.

18
I added the following code to "M5223x_boot.c".

Code: [Select]
        case DEVICE_ID_1_DATA_FLASH_32M:
            return AT45DB321D;

And in "fnCheckNewCode" it returns the wrong value for "file_header->usMagicNumber".

Thanks for the help.

Ewan.

19
I have an application which is working as expected. I use an AT45DB321 for file system and sw upload. I relinked the application to start at 0x1000. I used the Axiom programmer to program both .ELFs into flash. All seems to work fine. I set both the uTaskerConvert and the bootloader for no encryption. Using the "Administration Page" in the target, it appears that I can upload the new "H_Upload.bin" successfully. When the target resets (either from the software or a power cycle) the old program is still running. I modified the boot loader code as follows to account for a second device on the SPI pins and because I use the nWP pin on the memory chip.

Code: [Select]
extern int fnConfigSPIFileSystem(void)
{
  DDRAS |= PORT_AS_BIT3;
  _SETBITS(AS, PORT_AS_BIT3);                   // raise RC531 nCS   ewan

  DDRAN |= PORT_AN_BIT7;
  _SETBITS(AN, PORT_AN_BIT7);                   // raise AT45DB nWP  ewan

    PORTQS |= QSPI_CS0_LINE;                                         
    DDRQS |= QSPI_CS0_LINE;                                              // Drive CS line high

    PQSPAR |= 0x0015;                                                    // Set QSPI_CLK, QSPI_DIN and QSPI_DOUT on QS port

    QMR = ((QSPI_MSTR | QSPI_8BITS) | 2);                                // set mode and fastest speed

    if (fnCheckAT45dbxxx() == NO_SPI_FLASH_AVAILABLE) {
        QMR = 0;                                                         // disable SPI if no chip connected
        return 1;
    }
    return 0;
}

The affected ports work fine in the application. Any clues?

Regards,

Ewan.

20
µTasker general / Delayed ACKs
« on: November 16, 2008, 08:40:23 PM »
I read some discussions about the problems concerning delayed ACKs. I could not find if the uTasked used such things nor if there was a setup to disable them. Is it possible to tell a server (Windows for example) that it will receive only one packet and that it should ACK immediately? What do the following signify?
TOS_NORMAL_SERVICE
TOS_MINIMISE_DELAY
TOS_MAXIMISE_THROUGHPUT
TOS_MAXIMISE_RELIABILITY
TOS_MINIMISE_MONETARY_COST

I can see where they are used but I don't see why one is used instead of another.

Thanks,

Ewan.

21
NXPTM M522XX, KINETIS and i.MX RT / Re: Serial ports creating characters
« on: November 05, 2008, 11:52:01 PM »
Mark,

Thanks for the pointers. It is true that I was not receiving any characters. Overwriting made that obvious. I then put in a delay for 100ms before each read (just for the hardware testing) but still no joy. Then I thought it would be a good idea to add the following code.
Code: [Select]
    fnDriver(SerialPortID0, (TX_ON | RX_ON), 0);
    fnDriver(SerialPortID1, (TX_ON | RX_ON), 0);
All is working, and now on to other stuff.

Regards and thanks again,

Ewan.

22
NXPTM M522XX, KINETIS and i.MX RT / Serial ports creating characters
« on: November 05, 2008, 10:11:29 PM »
I have both ports interconnected so that I can easily check the hardware. The output of port 0 is connected to the input of port 1 and vice versa. I send a char 'A' which is then properly received according to the debugger. I then take whatever was received and add 1 to it (to get a 'B' hopefully). I then send the 'B' out on the other port and again (according to the debugger) the correct character is received. When I say character I mean that ucRx[0] = the character, and ucRx[1] = 0. My problem is that when I attach an oscilloscope to the second output there is not just a 'B' but a 'B' followed by an 'A'.
Code: [Select]
void fnRC531 (TTASKTABLE *)
{
  INTERRUPT_SETUP                 interrupt_setup;
  TTYTABLE                        tInterfaceParameters;
  static QUEUE_HANDLE             SerialPortID0, SerialPortID1;
 
  volatile unsigned char          receive, receive2;
  static unsigned char            FirstTime = TRUE;
 
  unsigned char                   ucRx[RX_BUFFER_SIZE];
  unsigned char                   ucLength;

 
  if (FirstTime == TRUE)
  {
    FirstTime = FALSE;
   
    tInterfaceParameters.Channel                 = 0;
    tInterfaceParameters.ucSpeed                 = SERIAL_BAUD_19200;
    tInterfaceParameters.Rx_tx_sizes.RxQueueSize = RX_BUFFER_SIZE;
    tInterfaceParameters.Rx_tx_sizes.TxQueueSize = TX_BUFFER_SIZE;
    tInterfaceParameters.Task_to_wake            = TASK_RC531;
    tInterfaceParameters.usConfig                = (CHAR_8 | NO_PARITY | ONE_STOP | NO_HANDSHAKE | CHAR_MODE);
   
    SerialPortID0 = fnOpen(TYPE_TTY, FOR_I_O, &tInterfaceParameters);

    tInterfaceParameters.Channel                 = 1;
    tInterfaceParameters.ucSpeed                 = SERIAL_BAUD_19200;
    tInterfaceParameters.Rx_tx_sizes.RxQueueSize = RX_BUFFER_SIZE;
    tInterfaceParameters.Rx_tx_sizes.TxQueueSize = TX_BUFFER_SIZE;
    tInterfaceParameters.Task_to_wake            = TASK_RC531;
    tInterfaceParameters.usConfig                = (CHAR_8 | NO_PARITY | ONE_STOP | NO_HANDSHAKE | CHAR_MODE);
   
    SerialPortID1 = fnOpen(TYPE_TTY, FOR_I_O, &tInterfaceParameters);

    PANPAR = 0;                                                         // return all ADC inputs to GPIO
    DDRAN &= ~PORT_AN_BIT0;                                             // set up direction for opto input
    DDRLD |= PORT_LD_BIT4;                                         // set up direction for opto output
    OPTO_ON();                                                          // needs 1ms to be detected
       
    interrupt_setup.int_type       = PORT_INTERRUPT;                    // identifier when configuring {25} - always initialise
    interrupt_setup.int_handler    = RC531_IRQ_OnInterrupt;             // handling function
    interrupt_setup.int_priority   = (INTERRUPT_LEVEL_1);               // interrupt priority level (this can not be modified for IRQ1..IRQ7 so the value is not really relevant)
    interrupt_setup.int_port_bit   = 1;                                 // The IRQ input connected
    interrupt_setup.int_port_sense = IRQ_RISING_EDGE;                   // Interrupt on this edge
    fnConfigureInterrupt((void *)&interrupt_setup);                     // configure test interrupt
   
    (void) OpenRC();                                                    // pins, speed & reset
    (void) Mf500PcdConfig(); 
    (void) Mf500PcdSetDefaultAttrib();
  }
   
  if (!Q_OPTO())
  {
    lamps (GREEN, OFF);
    lamps (RED, ON);
   
    return;
  }
 
  OpenCard();
 
  receive = ReadCard();
 
  if (receive == MI_OK)
  {
    lamps (GREEN, ON);
    lamps (RED, OFF);
  }
  else
  {
    lamps (GREEN, OFF);
    lamps (RED, ON);
  }
 
  // the output of port 0 is wired to the input of port 1 and vice versa
 
  ucRx[0] = 'A';                                      // send out an 'A'
  ucLength = fnWrite(SerialPortID1, ucRx, 1);         // on port 1
  ucLength = fnRead (SerialPortID0, ucRx, 1);         // read it back from port 0
  ucRx[0] += 1;                                       // make it a 'B'
  ucLength = fnWrite(SerialPortID0, ucRx, 1);         // send it on port 0
  ucLength = fnRead (SerialPortID1, ucRx, 1);         // read it back on port 1
 
 

//  uTaskerStateChange(TASK_RC531, UTASKER_SUSPENDED);  // run task only once for now
 
  return;
}

Another weird one.
Thanks,
Ewan.

23
NXPTM M522XX, KINETIS and i.MX RT / Re: More SPI issues
« on: November 04, 2008, 01:42:26 AM »
Well, perhaps just writing it down gets the brain thinking. Anyway -- problem solved. The routine above was being called by both the main program and an interrupt routine. (And reentrant is not sufficient with an I/O device.) I saved the state of the interrupt enable and dissabled that interrupt at the start of the routine. At the end I restored it.
Code: [Select]
void WriteRawRC(unsigned char addr, unsigned char value)
{
  unsigned char eport;
 
  eport = EPIER0;                             // save EPORT
 
  RC531_IRQ_Disable();                        // disable interrupt from RC531

  addr <<= 1;
  addr &= ~0x81;                              // fix up addr

  _CLEARBITS(AS, PORT_AS_BIT3);               // lower cs
 
  QIR = 0xd00f;                               // reset errors
  QAR = QSPI_COMMAND_RAM_0;                   // set address to first command location
  QDR = 0x0f00;                               // command to use no cs
  QDR = 0x0f00;                               // command to use no cs
  QAR = QSPI_TRANSMIT_RAM_0;                  // set address to first transmit location
  QDR = addr;                                 // save it
  QDR = value;                                // save it
  QWR = QSPI_CSIV | 0x100;                    // two sends
  QDLYR = QSPI_SPE;                           // QSPI enable (start)

  while (!(QIR & QSPI_SPIF)) {}               // wait for transfer to complete
  QIR |= QSPI_SPIF;                           // reset SPIF

  _SETBITS(AS, PORT_AS_BIT3);                 // raise cs
 
  EPIER0 = eport;                             // restore EPORT & reenable ints from RC531
}
I don't understand how all the weirdness happened in the first place, but it has gone away.
Ewan.

24
NXPTM M522XX, KINETIS and i.MX RT / More SPI issues
« on: November 03, 2008, 10:00:25 PM »
I have the SPI where I can read and write to a periperal without error when I do a couple of reads and writes then have a breakpoint to check the results. When I let the program run, it gets stuck in the while loop (see below).
Code: [Select]
// Write one byte to the reader IC address space
/*!
* -o  address  (IN) reader ic register address
* -o  value    (IN) 8 bit value
* return: none
*
* Function for writting one char to the reader module
*
*/

void WriteRawRC(unsigned char addr, unsigned char value)
{
  addr <<= 1;
  addr &= ~0x81;                              // fix up addr

  _CLEARBITS(AS, PORT_AS_BIT3);               // lower cs
 
  QIR = 0xd00f;                               // reset errors
  QAR = QSPI_COMMAND_RAM_0;                   // set address to first command location
  QDR = 0x0f00;                               // command to use no cs
  QDR = 0x0f00;                               // command to use no cs
  QAR = QSPI_TRANSMIT_RAM_0;                  // set address to first transmit location
  QDR = addr;                                 // save it
  QDR = value;                                // save it
  QWR = QSPI_CSIV | 0x100;                    // two sends
  QDLYR = QSPI_SPE;                           // QSPI enable (start)

  while (!(QIR & QSPI_SPIF)) {}               // wait for transfer to complete [stuck here]
  QIR |= QSPI_SPIF;                           // reset SPIF et al.

  _SETBITS(AS, PORT_AS_BIT3);                 // raise cs
}
The funny thing is that when I add a variable to it {test = QIR;} to test the loop, QIR equals 1 but the while loop continues anyway. Also the CS line has already been released. I cannot fathom how this is possible from several points of view. Does anyone have any ideas about this? When I disable the part of the program which deals with this stuff the ethernet/HTTP etc. works fine.

25
NXPTM M522XX, KINETIS and i.MX RT / Re: IRQ1 problems
« on: November 02, 2008, 11:13:00 PM »
Indeed, Mark.

Thanks,

Ewan.

26
NXPTM M522XX, KINETIS and i.MX RT / Re: IRQ1 problems
« on: November 02, 2008, 09:46:33 PM »
The problem was that there were other places in "application.c" that were setting the same interrupt. I commented them out and the new IRQ1 works fine. Of course, I now have a whole new set of problems not associated with the interrupt.

27
NXPTM M522XX, KINETIS and i.MX RT / Re: IRQ1 problems
« on: November 02, 2008, 06:04:24 PM »
Mark,

I can confirm that if I comment out fnConfigureInterrupt the problem does not occur. The device then raises its IRQ line as expected (but with no response from the CPU). When left as shown above, the failure takes place before the device sets its IRQ. I will now read the guide you suggested and dig deeper.

Thanks,

Ewan.

28
NXPTM M522XX, KINETIS and i.MX RT / IRQ1 problems
« on: November 01, 2008, 07:12:50 PM »
I have an SPI device with which I can communicate properly. It returns an interrupt (rising edge) which is connected to IRQ1 in the 80 pin package. The code is
Code: [Select]
void fnRC531 (TTASKTABLE *)
{
  volatile unsigned char          result, result2;
  static char                     FirstTime = TRUE;
  INTERRUPT_SETUP                 interrupt_setup;
 
  if (FirstTime == TRUE)
  {
    FirstTime = FALSE;

    interrupt_setup.int_type     = PORT_INTERRUPT;                       // identifier when configuring {25} - always initialise
    interrupt_setup.int_handler  = RC531_IRQ_OnInterrupt;                // handling function
    interrupt_setup.int_priority = (INTERRUPT_LEVEL_1);                  // interrupt priority level (this can not be modified for IRQ1..IRQ7 so the value is not really relevant)
    interrupt_setup.int_port_bit = 1;                                    // The IRQ input connected
    interrupt_setup.int_port_sense = IRQ_RISING_EDGE;                    // Interrupt on this edge
    fnConfigureInterrupt((void *)&interrupt_setup);                      // configure test interrupt
  }
 
  OpenCard();
 
  ReadCard();
 
  uTaskerStateChange(TASK_RC531, UTASKER_SUSPENDED);  // run task only once for now
}
I have a breakpoint set as follows
Code: [Select]
/*
** ===================================================================
**     Event       :  RC531_IRQ_OnInterrupt (module Events)
**
**     Description :
**         This event is called when an active signal edge/level has
**         occurred.
**     Parameters  : None
**     Returns     : Nothing
** ===================================================================
*/
void RC531_IRQ_OnInterrupt(void)
{
  RC531_IRQ_Disable();         // <--- the breakpoint is at the start of this line
  uEnable_Interrupt();
  SingleResponseIsr();
  RC531_IRQ_Enable();
}
When I run the program it never reaches the breakpoint. Instead it goes here
Code: [Select]
// default interrupt handler - and undefined interrupts will arrive here
//
static __interrupt__ void undef_int(void)
{
    while (1) {}                                                         // wait here and analyse with debugger....
}
If I comment out the interrupt_setup stuff the program does not work, of course, but I don't get the bum interrupt.
Where am I making a mistake?

Regards,

Ewan.

29
TeraTermPro can handle many serial ports. You have to modify the following in "TERATERM.INI".

; Max serial port number
MaxComPort=4


Just change 4 to 20 or whatever. Works great.

30
FreescaleTM MC9S12NE64 / Re: No memory from 0x8000 to 0xbfff
« on: October 17, 2008, 09:14:50 PM »
Well, it turns out that V 5.5.1272 that I said was for the IDE, not the innards. I now have V4.7 Eval.. There is now no problem whatsoever with compiling or linking the uTasker project. I wish it were so simple.

I have a P&E USB Multilink connected to a board with an NE64. I can download my old software (written by me before uTasker and using the banked model) and the new Metrowerks with the P&E works fine. Now, when I try to load the uTasker Monitor.abs to the target hardware I get the message:-
"Loading verification failed at 0x4000."

Any ideas?

On another barely related matter, I got my licence from Freescale but Metrowerks keeps asking me to register, which I already did. Is it limited to 64K or to 30 days or both?

Thanks.

Pages: 1 [2] 3