It is currently Sat Sep 22, 2018 1:41 am



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 36 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Flash re-work
PostPosted: Wed May 29, 2013 8:20 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
Currently the flash writing routine only supports pages up to 2048 and that is not going to do if we go to 32 bit as a standard so I guess a rework here is at the top of the list....and this is where I phone a friend or 2 and beg for help I think :?


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Wed May 29, 2013 11:08 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
Don't declare anything as a float or 32 bit INT if it's not necessary, and for the most part I don't think anything static needs to be a float or long INT, right?

Re-casting variables could be done in the formulae / calculations?

_________________
/me goes off to the corner feeling like Jerry Springer with a mullet.

My O5E candidate: 1982 Honda CX500TC motorcycle.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Wed May 29, 2013 11:41 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
abecedarian wrote:
Don't declare anything as a float or 32 bit INT if it's not necessary, and for the most part I don't think anything static needs to be a float or long INT, right?

Re-casting variables could be done in the formulae / calculations?



hmmmm...the point of a standard is that its...well...standard right? ;)


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Wed May 29, 2013 12:25 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
mk e wrote:
hmmmm...the point of a standard is that its...well...standard right? ;)

The point of memory management is managing memory efficiently, right?
;)

If you start bumping everything to 32 bit this or that, won't you be bumping against the compiler's limits too?

_________________
/me goes off to the corner feeling like Jerry Springer with a mullet.

My O5E candidate: 1982 Honda CX500TC motorcycle.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Wed May 29, 2013 4:09 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
abecedarian wrote:
The point of memory management is managing memory efficiently, right?
;)

We are currently at 2% usage.....memory usage is a non-issue.


abecedarian wrote:
If you start bumping everything to 32 bit this or that, won't you be bumping against the compiler's limits too?


No I don't think so. What I'm talking about changing is the user input stuff which doesn't count toward the compiler limit. Also, we aren't really using 16bit...it's 16+ code instructions to manage the bin points that come with basically every operation.....I'm thinking it will be a net savings on the compiler limit.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Wed May 29, 2013 5:29 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
Okay. I'll shut up. :?

_________________
/me goes off to the corner feeling like Jerry Springer with a mullet.

My O5E candidate: 1982 Honda CX500TC motorcycle.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Thu May 30, 2013 6:17 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
I may be able to help here.

I'm not exactly clear on the details of your hardware, but does it have a h7f flash device?


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Thu May 30, 2013 6:28 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
I'd love the help!

Good question...I have no idea but I'll ask.

We're using the on-board P&E jtag to load the FW into the onchip flash then the fw connects to TS and loads the user info though the serial port

Is this what you're asking?

This stuff is all on-board on the $99 TRK5634 dev board....and with CW it's pretty much a plug and play deal.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Fri May 31, 2013 6:39 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
I see.

So where is this 2048 limit?


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Fri May 31, 2013 8:18 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
patrick wrote:
I see.

So where is this 2048 limit?


In the it turns out poorly constructed flash code....well that's not fair. a couple years ago 2048 seemed fine but now 4096 is looking a lot better but doesn't work....there are apparently some cross dependencies in there somewhere that need to be resolved.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Fri May 31, 2013 10:42 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
Is that 2048 'bits' or 'bytes' or ?
What is the purpose of that code?

Is it pulling data from the tuning software and committing it directly to flash? If so, is it possible that the code isn't handling the incoming data stream properly, as in the code isn't up to handling the baud rate, and maybe needs to DMA data to SRAM then DMA back to FLASH?

_________________
/me goes off to the corner feeling like Jerry Springer with a mullet.

My O5E candidate: 1982 Honda CX500TC motorcycle.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Sat Jun 01, 2013 7:38 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
abecedarian wrote:
Is that 2048 'bits' or 'bytes' or ?
What is the purpose of that code?


Its bytes.

Is it pulling data from the tuning software and committing it directly to flash? If so, is it possible that the code isn't handling the incoming data stream properly, as in the code isn't up to handling the baud rate, and maybe needs to DMA data to SRAM then DMA back to FLASH?


The tune uses "pages" and defines a page size. the same page info is in the FW but the FW also has a max_page_size variable.....set to 2048. Yuo can set the variable larger than 2048 but it causes the processor to lock during flash operation.

The is also a buffer for incoming data set to 2048+10. IF the tuner thinks it has a page over 2048 it fails to read during it's initial compare step, but change that number to 4096+10 fixes that , the read/compare happens correctly, then the burn begins...and the processor locks.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Sun Jun 02, 2013 1:12 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:52 am
Posts: 304
Location: Over here, doing 'over here' things.
The "+10" is bits for handshaking or possibly parity checks?

_________________
/me goes off to the corner feeling like Jerry Springer with a mullet.

My O5E candidate: 1982 Honda CX500TC motorcycle.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Sun Jun 02, 2013 9:19 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
abecedarian wrote:
The "+10" is bits for handshaking or possibly parity checks?


I guess...I didn't write it and haven't dug very deep


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Tue Jun 04, 2013 7:09 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
Turns out the 56xx processors use a C90 device.

I've had a brief browse through your code.

Is there any particular reason you decided to re-implement the low level C90 flash driver in FLASH_OPS.{c,h} rather than using the standard FreeScale driver?

I would highly recommend you delete that code and integrate the standard driver.

Experience has taught me that these flash devices can be quite tricky to get right, often requiring the flash routines to be written in assembly (as the FreeScale ones are) to get the exact timings required.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Tue Jun 04, 2013 9:17 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
patrick wrote:

Is there any particular reason you decided to re-implement the low level C90 flash driver in FLASH_OPS.{c,h} rather than using the standard FreeScale driver?


I do not know the answer to that...Paul wrote it then Jon ans Sean tuned it up. Sean is quite familiar with these processors so I assume there is a reason but I'll have to ask him.

patrick wrote:
I would highly recommend you delete that code and integrate the standard driver.


Make a clone and give it a go :)


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Fri Jun 07, 2013 11:13 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
patrick wrote:
mk e wrote:

I would highly recommend you delete that code and integrate the standard driver.


Make a clone and give it a go :)


Patrick has kindly agreed to have a look at the flash issue....hopefully he can get this sorted.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Sun Jun 09, 2013 8:19 am 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
I'll look at this as soon as I get a chance.

Is there any documentation available about the TS serial protocol? Need to check some details.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Sun Jun 09, 2013 9:08 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
patrick wrote:

Is there any documentation available about the TS serial protocol? Need to check some details.


No there isn't unfortunately but if you have a specific question Phil normally answers them.

TS also creates a log
TunerStudioAppDebug.txt

telling you what it thinks when wrong. With this flash issue TS reports it lost serial connection which is exactly correct because the ecu processors is locking up and not responding.

To allow TS to read the larger pages there is a buffer in the FW that must be set large enough.....it's currently 2048+10 but needs to go to new_page_max+10.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Mon Jun 10, 2013 9:09 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
I really need to understand the serial protocol in order to attack this properly.

Does Phil read these forums?


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Mon Jun 10, 2013 9:25 pm 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
patrick wrote:
I really need to understand the serial protocol in order to attack this properly.

Does Phil read these forums?


No he doesn't.....he's busy so I mostly beg when I really need something cleared up. Sean can probably help though, I'll put an email together.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Tue Jun 11, 2013 7:26 pm 
Offline
User avatar

Joined: Sun May 19, 2013 8:32 pm
Posts: 12
I'm fairly well familiar with the serial protocol at this point, what do you need to know?


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Tue Jun 11, 2013 9:23 pm 
Offline
User avatar

Joined: Sun May 26, 2013 6:39 pm
Posts: 14
Is there a common structure for all serial commands?

looks like:

byte
0 length[0]
1 length[1]
2 command-id
3 data
...
length+2+0 crc[0]
length+2+1 crc[1]
length+2+2 crc[2]
length+2+3 crc[3]

but there's a few special cases with no length? (S,T,F,Q)
Is the data unaligned or am I missing an alignment byte?
Is the CRC aligned or just after the data?
Is there a minimum data size?
Is there a list of commands that TunerStudio sends available?

Do all responses have the same structure as above?

I think that's all I can think of for now.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Wed Jun 12, 2013 7:47 am 
Offline
User avatar

Joined: Sat May 11, 2013 9:45 am
Posts: 729
Location: PA, USA
patrick wrote:

Is there a list of commands that TunerStudio sends available?.



I'll see what I can find out on the list but the commands are listed in the ini and the flash stuff use:
burnCommand = "b\x00\x01" "\x00\x02",.....
pageReadCommand = "r\x00\x01%2o%2c", "r\x00\x02%2o%2c",...
pageReadCommand = "r\x00\x01%2o%2c", "r\x00\x02%2o%2c",.....
pageValueWrite = "w\x00\x01%2o%2c%v", "w\x00\x02%2o%2c%v",....
pageChunkWrite = "w\x00\x01%2o%2c%v", "w\x00\x02%2o%2c%v",.....
crc32CheckCommand = "k\x00\x01\x00\x00\x00\x04", "k\x00\x02\x00\x00\x00\x04",.......

The ram stuff use:
ochGetCommand = "A"

edit - these are in the ini too
versionInfo = "S" ; Put this in the title bar.
queryCommand = "Q" ; Verify against signature.


Top
 Profile  
 
 Post subject: Re: Flash re-work
PostPosted: Wed Jun 12, 2013 11:42 am 
Offline
User avatar

Joined: Sun May 19, 2013 8:32 pm
Posts: 12
This should be helpful:

Serial protocol:
http://www.msextra.com/doc/ms3/files/ms ... l_0.05.pdf

Old commands that the new protocol is wrapped around:
http://msextra.com/doc/ms2extra/RS232_MS2.html

O5E doesn't support all of those commands totally I don't believe, but it supports reading/writing memory locations as well as realtime variables.

Those are the two documents I used to communicate with both megasquirt and O5E. We can skype if you need more in-depth information on how O5E handles communications, I've been tinkering around in the Tuner.c file for the past month or two.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 36 posts ]  Go to page 1, 2  Next

Who is online

Users browsing this forum: Bing [Bot] and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Theme designed by stylerbb.net © 2008
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
All times are UTC - 5 hours [ DST ]