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

Pages: [1] 2 3
1
µTasker general / Re: uTasker + Windows 7 64-bit + VC 2010
« on: February 03, 2011, 03:36:42 AM »
Hi Mark,

As an update, I had to add the same "#ifndef _WINDOWS" for the "if (fnCalcIP_CS..." block in the fnHandleUDP function (udp.c), because of the same issue.

Did you make all of these adjustments in the most recent version of uTasker? 

Regards,
Paul

2
µTasker general / Re: uTasker + Windows 7 64-bit + VC 2010
« on: January 28, 2011, 04:31:32 PM »
HI Mark,

You were absolutely right.  I apologize, I interpreted the code snipped you wrote backwards.  With the code addition you provided, I can ping and get at the web page now.  I had some issues adding it originally because visual C refused to recompile the change.  Regardless, it seems to be working fine now.

I'm 99% convinced that it is a networking card issue (driver related), because I'm sure I had it working on this particular PC in the past, but do remember upgrading the driver a few months ago.

3
µTasker general / Re: uTasker + Windows 7 64-bit + VC 2010
« on: January 28, 2011, 04:03:18 PM »
Hi Mark,

Forgive my ignorance.  In trying to debug the issue, I'm seeing that the case IP_ICMP (even under ping attempts) in "Ethernet.c" is never getting executed  (in fnTaskEthernet).  However, when I launch a ping from the local PC, the fnHandleIP (ip.c) routine does get entered.  I don't understand how your modification addresses the issue though.  That is, doesn't the modification set the return value of fnHandleIP to "zero", and therefore, the switch statement in Ethernet.c won't get evaluated (because of the if statement)?
Code: [Select]
if ((usIPLength = fnHandleIP(&rx_frame, &usTotalLength)) != 0)
I'm not even sure I'm chasing the right ghost.  I'm having the exact same problem on my work PC (which I could have sworn worked some time ago), and my home PC.  The common thread with those two is that it uses a Broadcom ethernet driver, which I had to upgrade some months ago because it couldn't keep a stable connection to my switch..... I'm not sure if the NIC has anything to do with it or not.[/s]

Also, perhaps it may be good for me to get the latest revision of uTasker, so that all the updates are implemented.  At least that way I can ensure that a known good version (yours!) is working.....


4
µTasker general / uTasker + Windows 7 64-bit + VC 2010
« on: January 28, 2011, 03:51:19 AM »
After a long hiatus, I'm trying to get back into the uTasker world.  I recently updated computers to Windows 7 64-bit, and had to make the switch to VC 2010.

After some turmoil, I got my project (previously working--modification of the example) to compile, but I can`t ping it, or access any web pages.  It appears to be grabbing the correct IP address, and it talks to the outside world (ie: grabs the TIME as per the example), but that`s it.

I saw this thread post (http://www.utasker.com/forum/index.php?topic=180.0), but I see that the code is already updated in ip.c

It appears that something is getting through to uTasker, since putting a breakpoint in fnHandleIP triggers when a PING is initiated from another PC.

5
µTasker general / fnDebugMsg and debug.c
« on: June 10, 2010, 04:35:41 PM »
Hi Mark,

I'm working on an embedded ethernet project and want to have a setup menu system via TELNET.  This is already done in the uTasker demo app and works well.  However, since you've used fnDebugMsg to display the menus, all of the debug messages from the other modules are coming through this interface (ie: Modbus communications messages, etc..)

What I'd like is to limit the TELNET communication to the menus only, or better yet, allow the user to set the "debug level" to define the amount of debug information they see.

However, modifying fnDebugMsg seems daunting since its in the driver.c file (which I would like to avoid changing), as well as all the instances of fnDebugMsg being used throughout the modules.

Do you have an idea of how to overcome this?  I was thinking of changing "debug.c" to "menu.c", and defining a custom print function within that file, and allow fnDebugMsg to write to the network port only if the debug level is set high enough.....

If you have a better implementation idea, please let me know.....

6
µTasker general / Parameter System
« on: May 26, 2010, 09:30:48 PM »
Hi Mark,

I need to modify the uParameterSystem for my project.  The parameter system is quite complex, and I've had some trouble getting familiar with the architecture.  I understand that there are essentially four locations for parameters: two in RAM (working and temporary) and two in FLASH (valid and swap). 

Here is my understanding, please correct me if I am wrong:  you can use the RAM-temp parameters to make changes, and then commit them to the RAM-working and/or FLASH-swap.  When the FLASH-swap are validated (in case of critical--ie: ethernet changes), they are moved to the FLASH-working section and deleted. 

Also, I'm a little confused on the valid / validated bytes at the beginning of the block(s).  ie: why would we have a valid+validated SWAP block? 

I read the uFileSystem document that talks about fnSaveNewPars, fnGetPar, fnSetPar and fnDelPar.

However, I also see that there are other functions that deal with the parameters not described in this document.  This includes:

fnGetOurParameters()
fnGetOurParameters_1()
fnGetEthernetPars()
fnRetreiveAllParameters()

At first glace, it appears there is some redundancy here, but I'm sure there is a reason???


7
Luminary Micro TM LM3SXXXX / Re: Flash Protection
« on: May 19, 2010, 04:03:44 PM »
Hi, thanks for the reply.  Sorry if I'm thick, but I'm still a little confused.  Here is what I want to do:

1) Protect our code from competitors doing a read-back of the device
2) Protect the bootloader from getting overwritten (by firmware)
3) Allow the firmware to be written by the bootloader
4) Allow the firmware to read its own flash area, as parameters and user data are stored there
5) Allow the device to be "reset" such that the device can be wiped / re-programmed via JTAG or SWD

I don't mind disabling JTAG / SWD for another layer of protection, so long as we can revive it somehow if needed (ie: devices coming back from the field, etc).

What is the recommended method for protecting a device, yet allowing external firmware updates (via bootloader)?

Section 5.2.4.1 of the latest datasheet states:
Quote
Performing the sequence below causes the nonvolatile registers discussed in “Nonvolatile Register Programming” on page 158 to be restored to their factory default values. The mass erase of the flash memory caused by the below sequence occurs prior to the nonvolatile registers being restored.

So it seems to contradict the blurb in section 8.3.2

8
Luminary Micro TM LM3SXXXX / Re: Flash Protection
« on: May 19, 2010, 01:22:40 AM »
Here is a reply I got from our TI rep:

Quote
"Yeah, I would agree that the datasheet section 8.3.2 gives the impression that you cannot clear the flash protection once you commit it.  Well, that is not the case.  Refer the customer to datasheet section 5.2.4.1 (April 4, 2010 datasheet), "Recovering a Locked device".  By performing the proper JTAG pin toggling sequence, you can trigger a mass-erase of the device, which will clear the protection bits.  You can then get back into the device."

Now I need to figure out how to generate the "proper JTAG pin toggling sequence"


9
Luminary Micro TM LM3SXXXX / Re: Flash Protection
« on: May 18, 2010, 10:48:16 PM »
Mark,
I am in shock for lack of a better word.  This is simply idiotic, sorry for the frankness.

What is worse, is that it appears that their literature doesn't correlate:

Here is the exact text from a datasheet I have dated 10/13/2009

Quote
Important: These registers can only have bits changed from 1 to 0 by user programming. Once committed, the FMPREx and FMPPEx registers can only be restored to their factory default values only by performing the sequence described in the section called “Recovering a "Locked" Device” on page 62. The mass erase of the main Flash memory array caused by the sequence is performed prior to restoring these registers.

Notice the bold text.  The latest datasheet (dated 4/4/2010) has replaced this blub with the following:

Quote
Important: These registers can only have bits changed from 1 to 0 by user programming. Once committed, these registers cannot be restored to their factory default values.

Wow is all I can say......the boss isn't going to like this......

10
Luminary Micro TM LM3SXXXX / Re: Flash Protection
« on: May 18, 2010, 10:18:14 PM »
Mark,
I can't believe that this is an issue, and I basically assumed that flash protection was the norm now.  I am familiar with Microchip and Atmel methods of setting protection bits during programming.  The internal code still has access to the internal memory, but external debuggers /programmers read the code back as all zeros.  Moreover, in those implementations, a full chip erase sets un-protects all the "fuse bits".

This is a MAJOR deal breaker for us if we cannot protect our code efficiently.  It is not feasible to permanently disable JTAG, this takes us back 10 years to the days of OTP.

I am going to get in touch with TI immediately regarding this issue....either I'm missing something here or this is a total joke.

 :o :o :o :o :o

11
µTasker general / Re: TFTP Bootloader
« on: May 18, 2010, 07:58:00 PM »
OK, but won't the bootloader functionality change, because it won't be looking at the upper half of the memory space, but rather re-writing the flash as it gets accepted via POST?

12
µTasker general / Re: TFTP Bootloader
« on: May 18, 2010, 06:27:33 PM »
Do you have this type of bootloader already written, and could share it?

Regards,
Paul

13
Luminary Micro TM LM3SXXXX / Code Composer
« on: May 18, 2010, 06:14:35 PM »
Since the buyout by TI, it looks like they have made their Code Composer work for Stellaris.  Any feedback from users as to how Code Composer Studio compares to the other compilers?  I've been using the free command line G++ from CodeSourcery (mainly because the Simulator allows for a great IDE such as Visual Studio), however I've read that G++ isn't as efficient as others.

14
Luminary Micro TM LM3SXXXX / Linker Files
« on: May 18, 2010, 05:21:09 PM »
Mark,

For the LM project linker files, I noticed some differences between the regular one (1) and the _BM one (2).  Namely:

(1)  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x00040000
(2)  FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 0x0003f000

(1)  SRAM (wx) : ORIGIN  = 0x20000000, LENGTH = 0x00010000
(2)  SRAM (wx)  : ORIGIN = 0x20000000, LENGTH = 0x00008000

(1)  __HEAPSIZE__ = 4097;
(2)  __HEAPSIZE__ = 0;

(1)  __FLASH_segment_start__ = 0x00000000;
(2)  __FLASH_segment_start__ = 0x00000800;

I understand the FLASH_segment_start, but I'm not sure why the FLASH, SRAM and HEAPSIZE variables are different.

Granted, I'm not an expert, but I just wanted to make sure this is correct.

15
Luminary Micro TM LM3SXXXX / Flash Protection
« on: May 18, 2010, 04:50:37 PM »
Hi Mark,

I read your post from some time ago regarding your initial experiments with the LM Flash system.  You mentioned that you hadn't worked with the protection mechanisms.  Has this changed at all?  We would like to do everything possible to protect our code, but also need bootloader capability.

A few interesting peices of information from the LM3S6965 datasheets:

Quote
(Table 8-1): With FMPPEn = 1 & FMPREn = 0:
"The block may be written, erased or executed, but not read.
This combination is unlikely to be used."

Isn't this exactly the protection level that we want?  Does this mean external (JTAG) reads, or internal (program) reads?

Also, you mentioned that the Protection bits are write-once, but the datasheet states:

Quote
"Once the register contents are commited, the FMPREx and FMPPEx registers can be restored to their factory default values by performing the sequence described in the section called “Recovering a "Locked" Device” on page 62. However, the USER_REGx and USER_DBG registers can never be restored to the factory default values."

There is a procedure to restore the registers to factory default (described on pp. 62), but I'm not sure if the LM Flash Programmer is capable of this, so I'm wary of trying it on my demo board.

Moreover, from my previous experiences (Atmel, PIC), the protection is set via programming, whereas here it appears that the code (bootloader??) needs to setup these bits.

Can anyone comment on their experiences with the Flash Protection.

Pages: [1] 2 3