SM Re-Development in GCC + Customisations/fixes COMMENTS

[nitrousnrg]

EDIT: This thread is for comments on the SM Re-Development in GCC + Customisations/fixes thread.

FYI, I'm very happy about this :-)

How many people here have a programmer to make it happen?

[SleepyKeys]

For the most part I agree with your post except I would divide the tasks into two priority categories.

Since this effects the HW design I think things should go like this.

High: Get the changes made ASAP that free us from the goofy hw fixes. Even if that means using CW for the time being. "a" thats fine and the cool thing is you don't need to build it to test it "b" agreed but its time for functions that really matter like xgate BB etc, loader polishing etc.

Low:
"
Rewrite to be more simple and use more robust serial comms?
Rewrite to use another comms method such as CAN?
"
I prefer the FreeEMS spec coms, but I added a verify function in the loader to make sure your load is good. I have used Motec systems that used CAN over RS232, not sure we need it soon but could be nice.


All in all I don't see the SM mods/rewrite having a high priority since the HW work around(s) aren't too bad at the moment. Good idea posting though.

[Dan]

FYI, I'm very happy about this

How many people here have a programmer to make it happen?

It now appears I will have two!

[Dan]

EPIC! This will be EPIC! I want more injector and ignition I/O ! LOL

[Fred]

Marcos/Nitrous, at least 4 or more. Dan, glad you can help test and can load SM code to your new design! :-)

High: Get the changes made ASAP that free us from the goofy hw fixes. Even if that means using CW for the time being. "a" thats fine and the cool thing is you don't need to build it to test it :) "b" agreed but its time for functions that really matter like xgate BB etc, loader polishing etc.

1) We don't have to provide a usable SM s19 for the hw to be designed without the hacks.
2) We just have to prove that it is possible and provide a solution in a reasonable time frame.
3) "a" Builds that work on only one box (or are tested on only one box) are not considered a reliable source of a binary to test from.
4) "a" More than one of us needs to verify this process from start to finish, but....
5) "a" ...only one of needs to work on this, and it's me.
6) "b" see 5)
7) "b" This does really matter as it is permanent code from the point of view of any downstream user. How many MS2 boxes have revised SM code on them? None, probably, few at most. If we start shipping/burning broken SM code, people will need to live with it or get a BDM or get someone with one to fix their stuff.
8) "b" As for it taking up my time, I'm happy with where the firmware is, for the time being, and have other priorities right now, one of which, as stated two weeks ago (4pm Spanish time, June 29, 2011) it's frozen until more important things are sorted out. In that post I listed "hardware interface documentation" as one of the reasons. That document is one that I have to author, no one else. I'm responsible for the pin out and I have to live with the calls that are made. Feedback is good, and has come, and been used, and will keep coming, but I have to do it. So...

Leave this project in my hands. I've been working on it today, and will post when I have progress to report. I made some discoveries today that will likely strongly influence the direction of this project and I'm working on those to make it happen. My BDM is on its way from Canada and I've been looking into ways to use it under Linux. Things are well underway. Sean, your best bet is to focus on XGATE and Loader code, additionally, you could do refinements to the LT1 stuff if you want to test as you go, but I see that as "good enough" for the time being, and WAY less important than rewiring the EMS. I know it's hot there right now, so I assume you won't be working on the wiring/decoder, which leaves bench testing and loader and xgate stuff as your priority, in my eyes, which you can ignore. It'd be a shame to double up on work, though, and I am doing this task, whether you or others do it, or not. The reason is that it will take me just as long, or longer to go through others work in retrospect and hand verify every single byte of the image and every line of code change etc. Thus there is no point in me not doing it. I'll do it, others can verify that I didn't screw up, both theoretically, and empirically, and everyone can be happy! :-)

Low:
Rewrite to be more simple and use more robust serial comms?
Rewrite to use another comms method such as CAN?

Agreed, low, hence the task list being in order, and hence those being under a "perhaps other things" sub list.

I prefer the FreeEMS spec coms, but I added a verify function in the loader to make sure your load is good.

Sure, but there isn't a lot of point in burning flash memory lots of times because of multiple bad loads with dodgy connections, better to have a slow load that eventually definitely succeeds and is then double checked afterwards with a verify. In any case, those occasions are fairly rare, so it's not a high priority at all. It never was.

I have used Motec systems that used CAN over RS232, not sure we need it soon but could be nice.

Could be cool, lower than a good SM rewrite, though, I'd say.

All in all I don't see the SM mods/rewrite having a high priority since the HW work around(s) aren't too bad at the moment.

Although that is true, they are high priority because they are influencing the progress rates of hardware solutions, and we need progress in that area. Progress in that area is progress in firmware with testers testing. HW is THE priority right now, and this IS a prerequisite to it.

Excuse my firm tone, but I'm serious about this one. Jean and Marcos found that out some time ago. It's only recently become clear that this was the right approach to fix many things, so this is what we must do, and it is something that I must do personally.

Back to working on it! :-)

Fred.

[SleepyKeys]

"HW is THE priority right now, and this IS a prerequisite to it."

That was my take on it. Here is why I wanted to jump in.

-My Plan
1. Do what we need to do with the existing SM code in Code Warrior. That will allow HW designers to get back on it. Did I miss something or are we still talking about changing a few things with what it does with some of the pins???
2. Do a gcc port/feature add LATER.

- Your Plan
Spec this port that, do a complete rewrite etc.

Anyway I'm retracting my enthusiasm to help on this so just a couple more questions. I know the SM program isn't huge but what kind of time frame do you have in mind?

"The reason is that it will take me just as long, or longer to go through others work in retrospect and hand verify every single byte of the image and every line of code change etc."
True it does take just as long or longer to do that BUT I still don't understand why you would do that as long as you can verify that it does what it's supposed to do. You act like I proposed not doing any testing at all or taking shots in the dark and calling it good, what am I missing? When I did the flash burn code we did burns and rips to make sure it did what it was supposed to do. When I finish the xgate code we will verify with a LA/Scope, no need to look at every line of code right?

-sean

[Fred]

-My Plan
1. Do what we need to do with the existing SM code in Code Warrior. That will allow HW designers to get back on it. Did I miss something or are we still talking about changing a few things with what it does with some of the pins???
2. Do a gcc port/feature add LATER.

Of course SM code sets with different features will come later. I have NO plans to do that now what-so-ever. I just want to fix the two things that are preventing hardware from being developed and maybe the thing that stops hcs12mem from working correctly. That's it. 2k bytes is max 1k lines, it's more of a literal rewrite than a redevelop, not the same thing. Totally different scope.

- Your Plan
Spec this port that, do a complete rewrite etc.

Don't understand "spec this port that", don't want to redevelop it, just rehash it in GCC ASM.

I know the SM program isn't huge but what kind of time frame do you have in mind?

Before my BDM arrives and is usable which comes before the compliance document is published which comes before anyone finishes anything resembling a compliant board. In short, this thread and any work on the SM do not in ANY way stop people developing hardware! It doesn't even stop them completing their design and having it manufactured once we prove one tiny thing that is provable without a BDM. The ONLY thing it stops, at this point, is a finished compliant board functioning correctly, and maybe not even that.

I still don't understand why you would do that as long as you can verify that it does what it's supposed to do. You act like I proposed not doing any testing at all or taking shots in the dark and calling it good, what am I missing? When I did the flash burn code we did burns and rips to make sure it did what it was supposed to do. When I finish the xgate code we will verify with a LA/Scope, no need to look at every line of code right?

Firstly, no, I don't act like you propose to not do any testing at all or take shots in the dark and call it good. What I'm acting like is that this is serious and it will be blanket tested, EVERY function will be verified in every way, end to end. This will be done with serial line tests, code inspection/diffs, binary inspection/diffs, physical/electrical tests. When all tests are passed, A OK and verified by at least one other reputable person, you if you like, then it will get checksummed and published as the new standard FreeEMS compliant SM s19.

What you're missing are these two points and their combination:

1) This is not user erasable, bugs are, more or less, permanent.
2) It's easy to break things unless they are done in a controlled way.
3) This is not user erasable, bugs are, more or less, permanent, and if we break something, we're stuck with it, or have issues with people upgrading etc.

Don't take it personally. This matters as much as any other piece of work in the project, and in many ways more. This NEEDs to be right because there isn't really a second chance with it. I'm taking a mission critical approach, because A it is B it's small enough C this could affect the reputation of FreeEMS D i care about that very much.

Fred.

[SleepyKeys]

"stops hcs12mem from working correctly." - I wonder if that's a hardware bug

I don't. If you need a hand testing let me know.


I'll still try to defend my timely approach vs 'obsessive'(don't take that the wrong way). Change a few lines from below to suite our needs and run compile

Code: Select all

;**********************************************************************
; Decide whether to go to user reset or bootloader/monitor
;**********************************************************************
; (a) default to monitor if high byte user pseudo-vector is erased ($FF)
;**********************************************************************
             ldab vector00-($10000-BootStart) ;check for user reset Vector
             comb ;if erased COMB result will be 0
             beq Monitor ;default to monitor if no vector

;**********************************************************************
; Test the state of some pins to force entering the monitor
; Depending on the hardware configuration enable/disable/modify the
; sections below
;**********************************************************************
             bset SwPullup,mSwPullup ;enable pullup on force monitor sw
             bset PPSS,PPSS0 ;enable pullup on RxD0 pin
             bset PERS,PERS0 ;on RxD0 pin
             clrb
             dbne b,* ;delay to allow sw pin to pull up
;**********************************************************************
; (b) force monitor if SwPort bit SWITCH = 0
; Note: this port is configured after reset as input with pull-up
; With no connection to this pin the monitor jumps to run mode
;**********************************************************************
             ldab SwPort ;get port value
             bitb #Switch ;test the sw bit
             beq Monitor

;**********************************************************************
; (c) force monitor if RxD low (from host) PORTS bit 0
; This is true if the host holds RxD on break level
; Note: this port is configured after reset as input with pull-up
;**********************************************************************
             brclr PTS,PTS0,Monitor ;to monitor if RxD low
             bclr PPSS,PPSS0 ;restore reset state on RxD0 pin
             bclr PERS,PERS0 ;restore reset state on RxD1 pin

;**********************************************************************
; finally jump to the user application (by pseudo vector)
;**********************************************************************
             jmp [vector00-($10000-BootStart),pcr] ;go where
                                        ;user reset vector points
;*********************************************************************
; Formal start of Monitor code

[Fred]

"stops hcs12mem from working correctly." - I wonder if that's a hardware bug

I don't. If you need a hand testing let me know.

I don't understand what you mean, but I've known that it was a bug in the SM since late October 2008, approaching 3 years ago. It's straight forward to test, just fill the flash with garbage, then send a simple command as per the manual (or with hcs12mem that is as per the manual) and watch it mass erase all four blocks in parallel. Like the other changes, though, this WILL need verification in code, binary and functionality, by you and/or others.

I'll still try to defend my timely approach vs 'obsessive'(don't take that the wrong way). Change a few lines from below to suite our needs and run compile :)

Sean, you can absolutely call me anything you like now, the language filter has been off for months, do your worst, BUT, when I prove myself right, and I will, you must promise to kiss my arse (British spelling) and apologise (also British spelling), OK? This is a reciprocal arrangement, in the event that the underlining on "will" was out of place ;-)

Fred.

[SleepyKeys]

If the SM just loops the sector erase command though the block like the loader it will 'look' like the chip is frozen for a few secs.

I don't mean to call you names, maybe fire you up a bit that's all. If 2012 rolls around and it's not done then maybe I will