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 - johnr

Pages: 1 2 [3] 4 5 ... 7
31
NXPTM M522XX, KINETIS and i.MX RT / Register passing in SP5
« on: February 04, 2008, 11:08:36 PM »
Mark, how hard is it to enable register passing in the SP5 code, assuming we
recompile any libs, and check the assembler .S files for param passing ?

 Thanks,
 John

32
NXPTM M522XX, KINETIS and i.MX RT / Re: LCD Display
« on: January 17, 2008, 05:56:42 PM »
Mark, after applying the SP5 fix to uTasker.c, I noticed when I set

#ifdef SUPPORT_LCD
 { "LCD",       fnLCD,          MEDIUM_QUE,  (DELAY_LIMIT)(.01 * SEC), 0, UTASKER_STOP},  //
#endif

that the LCD and APPLICATION tasks only run once. The WDOG runs
continuously. After removing the startup delay to LCD everything runs OK

Thanks,
John
 

33
NXPTM M522XX, KINETIS and i.MX RT / Re: LCD Display
« on: January 16, 2008, 04:14:00 PM »
Mark,
 When I  changed

#ifdef SUPPORT_LCD
 { "LCD",       fnLCD,          MEDIUM_QUE,  (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},  //
#endif

to

#ifdef SUPPORT_LCD
 { "LCD",       fnLCD,          MEDIUM_QUE,  (DELAY_LIMIT)(.01 * SEC), 0, UTASKER_STOP},  //
#endif

 the WDOG task stopped running. Changing it back to no startup delay
fixed the problem. I didn't notice any other problems, but I was only doing some web and serial port testing.

 Thanks,
 John

34
NXPTM M522XX, KINETIS and i.MX RT / Re: LCD Display
« on: January 15, 2008, 11:05:19 PM »
Mark, with the LCD enabled ,the fnLCD() never breaks in the debugger ,which call fnRetriggerWdog(). LED3 does blink though. What can I break on to determine the timer is
working ?

 Thanks,
 John

35
NXPTM M522XX, KINETIS and i.MX RT / Re: LCD Display
« on: January 15, 2008, 06:00:28 PM »
Mark, I noticed when I have LCD support that LED1 doesn't blink anymore
because the WDOG doesn't run. When I disable LCD support the WDOG runs

 John

36
NXPTM M522XX, KINETIS and i.MX RT / Re: LCD Display
« on: January 09, 2008, 08:24:23 PM »
Mark, I changed the LCD task start delay to 10ms and
now place the 40us delay in fnWriteDisplay() before writting the
first nibble and it works. When compiling with full optimization
I had to add the pragma in the delay function. I found you do
a simalar hard delay loop in other code and borrowed
the timming parameter, 556 iterations=1us

 The code also works with a NHD-0420DZ LCD with backlight

 Thanks,
 John


void DelayUS(int aUS) {
#pragma global_optimizer off

int   ulDelay;

   for (ulDelay=556*aUS; ulDelay >0; ulDelay--);
}

37
NXPTM M522XX, KINETIS and i.MX RT / Re: Web binary file download
« on: January 08, 2008, 08:51:59 PM »
Thomas , thanks for the help. I tried all kinds of headers
with no luck with IE . Next time I get into this I'll try this out.

 John

38
NXPTM M522XX, KINETIS and i.MX RT / Re: LCD Display
« on: January 08, 2008, 08:49:11 PM »
Mark, I got the SP5 code to work by delaying 35us
at the end of _fnWriteDisplay(), which writes out each 4 bit nibble . I am able to write to all 4 lines of the 20416H LCD. I also started the LCD task with a 50ms delay to ensure power up initialization of the LCD, which the spec says is 10ms. Not sure if this was needed though.

 Thanks for the help ....
 John

39
NXPTM M522XX, KINETIS and i.MX RT / Re: LCD Display
« on: January 07, 2008, 06:12:11 PM »
Mark, we have read the post for the LCD display. It pretty much describes what we have to do. We are using 4 bit mode. I have found that in order to be able to break on a line in a C source file you must ensure that the debug dot is displayed in the left hand Project pane for that file. This column is checked for most C files. Clicking on the column toggles the flag. I have disabled optimization so I can step through the code.

 I'll let you know my results ...

 Thanks,
 John

40
NXPTM M522XX, KINETIS and i.MX RT / LCD Display
« on: January 07, 2008, 04:50:59 PM »
Hi ,
 We're trying to run a HDM20416H LCD display, which is 4 lines*20 chars. I #defined
SUPPORT_LCD and the LCD works in the Simulator. When I run it in the real board
I get part of the "Hi uTasker !"  msg displayed. It looks like the timing may be off or we're writing to the wrong display memory for this chip. I tried adding redundant writes in
CLOCK_EN_HIGH and LCD_DRIVE_DATA to stretch out the timing but it still didn't work.
The registers and bit masks for this LCD look the same as the one uTasker is setup to use.

 I want to debug this using CW 6.3 light, but it doesn't break on any code in LCD.C.
I notice that when you have the source code displayed in the right hand pane, in the
left hand column of the source code there are dash lines where you would click on to set a break point. After setting the break point a red ball would appear. Some source file have dashed lines where the red ball is displayed and you can set breakpoints in these files, unfortunatley they do not show up in LCD.C. Anyone have any idea why this happens ?

 Thanks,
 John
 

41
NXPTM M522XX, KINETIS and i.MX RT / Re: SW upload via Web post
« on: November 13, 2007, 07:48:34 PM »
Thanks Mark, We'll probably use one of the larger flash chips.

 John

42
NXPTM M522XX, KINETIS and i.MX RT / Re: SW upload via Web post
« on: November 13, 2007, 06:02:44 PM »
Mark, I made the changes in uTaskerBootLoader.c to reflect the new code size.
I am starting the File system at 0x1E000 which gives me 120K of code and I'm
loading it at 0x1F000, which is above the parameter blocks. Everything works
OK now. When we go with a SPI EEPROM I can increase the code some more
if we need to until we run out of file system space. What is the largest
EEPROM you would recommend that we use ? We plan on do some datalogging
and storing the data on top of the SW upload area.


 Thanks for the help,
 John

43
NXPTM M522XX, KINETIS and i.MX RT / SW upload via Web post
« on: November 12, 2007, 10:46:24 PM »
Hi, I'm trying to do a SW upload via a Web Post after increasing the
code size from 96K to 104K. I do not have SPI_SW_upload enabled. When I leave the code size at 96K I can do the upload and see the new version displayed. I increase the code size in app_hw_m5233x.h as follows:

Code: [Select]
// FLASH based File System setup
//
#ifdef FLASH_FILE_SYSTEM
    // #define uFILE_START 0x18000                                          // FLASH location at 96k start
    #define uFILE_START 0x1A000                                          // FLASH location at 104k start

    #define SINGLE_FILE_SIZE (1*FLASH_GRANULARITY)                       // each file a multiple of 2k
    //#define FILE_SYSTEM_SIZE (80*SINGLE_FILE_SIZE)                       // 160k reserved for file system (including parameter blocks)
    #define FILE_SYSTEM_SIZE (76*SINGLE_FILE_SIZE)                       // 152k reserved for file system (including parameter blocks)
#

 I change every instance of 160*1024  as follows in webinterface.c

//#if FILE_SYSTEM_SIZE >= (160*1024)                                   // support posting new firmware only with large file system
    #if FILE_SYSTEM_SIZE >= (152*1024)                                   // support posting new firmware only with large file system
 

 After changing the file system size I erase the whole flash and program
in the boot loader and BM code.  I then change the version number,
run make and bm_convert.bat to generate the H_Upload.bin.
After selecting the file and hitting the upload button it says
upload successfull, reboot in 10 sec. After rebooting it displays the old
version. Am I missing something in the code ?


 Thanks,
 John

44
NXPTM M522XX, KINETIS and i.MX RT / Re: Flash memory layout
« on: November 06, 2007, 09:11:14 PM »
Hi  Mark, thanks for clearing this up. I thing 120K code should be enough for
our application, I hope :)

 John

45
NXPTM M522XX, KINETIS and i.MX RT / Flash memory layout
« on: November 02, 2007, 06:43:40 PM »
Hi, I've been reading though the docs and code and have
a few questions concerning the memory layout. The code size
is limited to 96K and the file system size at 160K. Being you can
use up to 62 files, each mapped to a 2K block, this allows up
to 62*2=124K of space allocated for files. I see that the SW upload
code checks for at least 160K file size.
 Is it possible to increase the code size and decrease the file system
size and still have SW uploads ?

 Thanks,
 John


Pages: 1 2 [3] 4 5 ... 7