Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000457TunixFreeEMS Pluginpublic2011-12-02 10:392011-12-02 19:00
ReporterFred 
Assigned ToFred 
PriorityhighSeverityminorReproducibilityrandom
StatusclosedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24 
Summary0000457: Trying To Write Unwritable Location IDs
DescriptionI believe that when you pull the data from the device you do so indiscriminately and thus when writing data back the first time, it errors on the RO blocks (such as counters) which can only be written to with the bench test firmware (which is possibly why you've not noticed this).

Packet ERROR Code 0x4008, "Invalid Memory action for ID!"
BURN Flash Response PACKET NACK ERROR. Ack! I Don't know what to do now!!!!

The concerning thing is that if you click it a few times it stops erroring and the burn button goes un-red. What could cause that? It should always error and never go un-red if it's trying to write a "dirty" RO block down. Also, it doesn't always display this error when you press the burn button, though when it doesn't display the error, it doesn't go un-red either. There are some problems in this area, but I don't understand them well enough to offer suggestions.
Additional InformationNo suggestions except to pull only the tunable data that makes sense. For a start, remove RO stuff from that query by setting the flag appropriately. I should probably fully document the semantics of it at some point, but don't have time right now. Enough is documented to remove the RO stuff. If that's all you do, then you'll be getting some duplicate data. Probably the best thing to do for future firmware compatibility is to only get stuff that ((is a child || has no children) && !(is read only)) This would mean that I could shuffle children around inside a block (which I want to) without affecting validity of saved data. However just removing RO stuff from the list will prevent the error. The other behaviour, I have no idea about, seems like a bug, though. I just updated that temp copy of the vanilla doc a little more for you too.

http://stuff.fredcooke.com/VanillaSerialProtocolInterface.pdf [^]
TagsNo tags attached.
FirmwareVersion
Attached Files

- Relationships

-  Notes
(0000836)
dandruczyk (viewer)
2011-12-02 13:27

WHERE IS THE DETAILS!!?? i.e. what the hell were you doing in the UI? This ticket does not have ONE GOOD THING I CAN USE to even try and replicate what the hell you seem to experience. Go back and re-read your description...

You need to STOP, STEP BACK and relay the CONDITIONS leading to this (firmware in use, OS, anything pertainent), the STEPS TAKEN (I did this, this and this), the EXPECTED result (It should have done this, this and this), and the ACTUAL result (It did this, which isn't according to spec, and this is why I think that...). Without that sort of info, this ticket is largely vague and of little help.
User avatar (0000841)
Fred (administrator)
2011-12-02 13:47

Please re-read. Burn button = "Permanently Store Data in ECU" Pressing this gives the error and other red/non red error/non error behaviour described above. I set the issue reproducability to random because I couldn't notice a consistent pattern in what it did, though I'm sure there is one, I don't know what it is. Please at least play with it before whinging about the description more. I can't do better than the above plus decoding "burn button" into your language. BTW, burn button and read button are on the ve/ign/lambda tabs (in case you'd forgotten) :-p
(0000845)
dandruczyk (viewer)
2011-12-02 15:15

i.e what did you do to make the burn button go red?
(0000846)
dandruczyk (viewer)
2011-12-02 15:26

Implemented some code to deal with read only locations.

see git hash 39cb8b147f8b3b46f30b7f19986d82ae58edc0de
User avatar (0000847)
Fred (administrator)
2011-12-02 17:06

What I did was either just navigate through cells due to the other bug, or edit a cell. I've just saleaed this and the packets get responded to just fine, the only trick is that they don't have a sequence number. It seems like your code finds the packet with the right payload, clears its "not found" flag and fails to alert the required other code due to lack of sequence.

Additionally, as a test, I held down reset and sent a burn and predictably it timed out and resent a few times, and the odd thing, the first resend had sequence zero:


fred@cheetah:~/sj$ mtxf0
timeout, no packet found in GENERIC_BURN queue for sequence 0 (00), locID 8
timeout, no packet found in GENERIC_BURN queue for sequence 1 (01), locID 8
timeout, no packet found in GENERIC_BURN queue for sequence 2 (02), locID 8
timeout, no packet found in GENERIC_BURN queue for sequence 3 (03), locID 8
timeout, no packet found in GENERIC_BURN queue for sequence 4 (04), locID 8
timeout, no packet found in GENERIC_BURN queue for sequence 5 (05), locID 8
timeout, no packet found in GENERIC_BURN queue for sequence 6 (06), locID 8

it was found and accepted (red went away) as soon as I let off the button and it received the command. I can't really test the other code re RO stuff as I can't get normal behaviour out of it in the first place, though it seems fine and I've not seen that error again, so I presume that your implementation works fine. This can stay open till the other weirdness is gone and I can conclusively prove that it's working right.
User avatar (0000848)
Fred (administrator)
2011-12-02 17:07

It's your requests for burns that don't have sequence numbers, the replies follow suit, of course. Assigning to you for the time being.
(0000851)
dandruczyk (viewer)
2011-12-02 18:46

The zero sequence is fine. For certain operations (burn, ram write, flash write), have dedicated queue's assigned to the that match on payload ID ONLY.


Latest push includes several fixes, please, pull rebuild and re-test.
7b3830ade81fc14c068071cc98239093ea8bef9c
User avatar (0000856)
Fred (administrator)
2011-12-02 19:00

Works well enough for the time being. Good to hear that you're using payload IDs for what they were designed too! :-) We might need to revisit this at a later date, but for now it's 100% fine: Closing!


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker