reset versus F10 versus F11

bozo · 2011-12-18 19:06

Hi all,

the behaviour of one of my programs is not consistent between the following 3 events:

(a) manual reset (pushbutton on Resn)
(b) compile and load RAM
(c) compile and load EEPROM

For cases (a) and (b), the behaviour is similar, but for case (c) it is slightly different.
In all cases it is the same code that is either being reset or loaded.
I'm using Brad's spin tool, and the C3.

I have no idea what is going on here. The program works fine when it is kicked off after loading to EEPROM.
It was only when I was testing its behaviour after manual reset that I noticed the discrepancy.

The differences in behaviour are totally repeatable each time.

Does anyone have any clues?

note: for what it's worth, my program is not writing anything into the EEPROM, and the discrepancy I am seeing is related
to using the full duplex serial object

thanks,

ElectricAye · 2011-12-18 19:24

Just a thought: whenever you push F10 or F11, you are loading the program that is in your present screen. In the past, I've screwed up by accidentally switching to a different version of the same program because I clicked to its tab but didn't notice, then loaded the thing into RAM or EEPROM, then tabbed back to the software I had thought I had loaded and couldn't understand the discrepancy. I doubt that's your problem, but I thought I would throw that out there.

bozo · 2011-12-18 20:16

thanks for the suggestion ElectricAye, but I only have the one version open

I did some more testing and noted that if I add a 3-second delay before calling my first cognew(), it makes a difference.
Is there some minimum timing requirement that needs to be observed? I wouldn't have thought so?

kuroneko · 2011-12-18 20:26

bozo wrote: »

I did some more testing and noted that if I add a 3-second delay before calling my first cognew(), it makes a difference. Is there some minimum timing requirement that needs to be observed? I wouldn't have thought so?

cognew itself doesn't have a timing requirement. Would it be possible to see some (minimal) test code?

bozo · 2011-12-18 20:50

OK here's some code ... not sure how helpful it will be ... I am using my prop to talk to my Suzuki motorcycle ECU (engine control unit) via the OBD port ...

the first code to execute is this: (note the 3 second delay here makes all the difference to behaviour at reset)

CON
  _CLKMODE      = XTAL1 + PLL16X
  _XINFREQ      = 5_000_000
  ...

VAR
  long stack1[99], stack2[99], stack3[99], stack4[99]
  ...

PUB main
  waitcnt(cnt+clkfreq*3)
  cognew(cogEcu,  @Stack1)      'handles all comms with ECU
  cognew(cogLcd, @Stack2)       'handles all comms with LCD
  cognew(cogMaths, @Stack3)     'performs conversions from r2108[x]
  repeat
    waitcnt(clkfreq+cnt)
    ...

note here that the LCD and Maths cogs are not in question, they simply drive a LCD display and do some maths
the other cog though handles serial comms to an ECU, this is the problem area ... in here is a call to start up a full duplex serial object (below)

the discrepancy in behaviour I am seeing is related to the serial comms between my prop and my ECU - when I load to EEPROM, the propeller
talks to my ECU perfectly, but when I trigger a manual reset, it fails to 'wake up' the ECU (unless I have the 3-second delay at
the start of my code).

I would have thought that there should be no difference in behaviour of the propeller whether it is coming out of reset from a load to
EEPROM or load to RAM or just a plain manual reset. ??

PUB cogEcu | a,b,idx,len,cntStart
  repeat 'forever
    fastInitCount := 0
    repeat 'until comms init is OK
      fastInitCount += 1
      initCommsOK := notOk
      'FAST INITIALIZE THE ECU
      'refer s5.1.5.3, ISO 14230-2
      outa[pinTxEcu] := 1           'set Tx pin to output and drive it high
      dira[pinTxEcu] := 1           'this ensures the SDL line is high (idle) to start with
      waitcnt(cnt+clkfreq)          'it needs to be high for more than 300mS
      cntStart:=cnt
      outa[pinTxEcu] := 0           'pull it low
      waitcnt(cntStart+clkfreq/40)  'wait 25mS
      outa[pinTxEcu] := 1           'then release
      serialEcu.start(pinRxEcu, pinTxEcu, 0, 10400)     'and start up high speed comms with ECU
      waitcnt(cntStart+clkfreq/20)  'total 50mS
      dira[pinTxEcu] := 0           'then release control of the line (it will be kept high by serialEcu)
      'ATTEMPT TO INITIATE COMMS SESSION
      serialEcu.tx($81)
      serialEcu.tx(ecuAddr)
      serialEcu.tx(testerAddr)
      serialEcu.tx($81)
      serialEcu.tx($05)
     ...

cheers,
Mark

sidecar-racer · 2011-12-18 21:10

Mark, Perhaps more delay is needed for the Suzuki ECU to respond?
I'm working on a data acquisition system (propeller, GPS, A/D channels, Wheel speed, rpm, etc) for our
Bonneville sidecar (GSXR1000K6, LCR)
Perhaps we couild compare notes???
Rick Murray

bozo · 2011-12-18 21:23

hey Rick, that occurred to me but it doesn't explain why it works fine without the delay in there when it runs after a load from EEPROM.

I'm happy to share whatever you like ... all I am doing is using the OBD port and pulling all the sensor values out of my ECU and displaying them on a 16x2 LCD (and later I want to write logged values to the SD card in the C3). So far I can pull out the RPM, throttle position, intake air pressure on each cylinder, water temp, air temp, battery voltage, ignition advance angle, and gear position. All comms are at 10400bps and use KWP2000 (key word protocol 2000).

cheers,
Mark

kuroneko · 2011-12-18 21:41

bozo wrote: »

... but it doesn't explain why it works fine without the delay in there when it runs after a load from EEPROM.

Just thinking aloud here. Load to RAM is fastest as it only involves the upload. Load to EEPROM involves upload + programming time. Finally, a manual reset takes about 1.3sec to fill hub RAM with the EEPROM data. Assuming that reading the 32K is faster than writing/programming it, load to EEPROM has the longest delay between reset and program start (which singles it out). Does that make sense?

bozo · 2011-12-18 21:56

that makes perfect sense, but my ECU doesn't know that the propeller is going through a reset ... it's just sitting there waiting for an instruction ... unless ...

... unless, ... unless it can't handle being woken up by the 'fast init' process until some sort of timer expires in the ECU - and the load EEPROM time is sufficiently long enough to let that timer expire and allow the ECU to be receptive to another fast init ...

I think that might be it!

Time to re-read the specs on OBD.

Thanks for the thinking aloud. Sometimes it is very helpful!

cheers,
MarkW

Toby Seckshund · 2011-12-19 01:20

On some of my copies of a DracBlade I used to get different results from powering up, and doing a reset on a powered up board. I tried all sorts of things like beefing up the supplies and putting a 1 second delay on start up, nothing seemed to change it. The two remaining boards I have running are both the full 3 latch ones and seem to start ok, thankfully.

These were complied on BST, not that I can see that it would change anything.

One other thing that I found was that some of the pins (p28 & p29) put out some pulses that I didn't expect from a reset.

sidecar-racer · 2011-12-19 08:00

Mark,
Let us know what you find.
After I thought a bit, I should ask the question of which Suzuki. The system on a motorcycle and a car are very different. (Bike has no ODC port, even internal access is done by cutting open the magic box.
Rick

bozo · 2011-12-19 17:04

sidecar-racer wrote: »

Mark,
Let us know what you find.
After I thought a bit, I should ask the question of which Suzuki. The system on a motorcycle and a car are very different. (Bike has no ODC port, even internal access is done by cutting open the magic box.
Rick

I'm now confident that the problem was with my code. i.e. its behaviour on reset assumed that the ECU required a 'fast init' to wake it up ... which is certainly does need if I am loading to EEPROM, since the ECU kills a comms session if there's no activity for a while. The specs suggest a typical value of 5 seconds, but there is no minimum value recommended and I think my ECU must use a value closer to 2 or 3 seconds. Thus the manual reset (and also the load to RAM) scenarios saw my code trying to wake an ECU that was already awake and hence the variation in behaviour.

Sidecar, you are on the money with bike ECUs. I've had to cut open my ECU and soak it acetone in order to get to the internals and pull code out of it. Even though there is no OBD port on the bike, fortunately there is a serial data comms line brought out to a special connector for the dealers to plug into, and that's what I'm using. It's not easy to find retailers who sell automotive connectors. And even when you do find one, there are so many hundreds of different types of connectors it is hard to know which ones to buy. Fortunately I got it right on the second guess, so now I have a few 'dealer-only' connectors to use.

oh, I am playing around with a Suzuki SV1000 (V-twin) - I really like the idea of real time sensor data on the dashboard, and especially the idea of having the intake pressure sensor data on display for when it comes to balancing the throttle bodies ...

cheers,
Mark

pedward · 2011-12-19 20:43

The problem is that BST is issuing a DTR reset when the serial terminal is reconnecting to the propeller after a RAM download. This behavior is similar when you disconnect and reconnect using the terminal, as when you connect, it will reset the Prop. This seems to be a known problem with BST, since I've experienced and saw a note where someone else pointed out similar behavior.

reset versus F10 versus F11

Comments