Long address bug?

[Trond]

I think I might have found a bug.

It seems that the decoder does not respond when programmed to certain long addresses.  I think I have narrowed it down to being addresses where bit 4 in CV17 is set.
Can someone test and confirm or deny this?


Addresses I have tested:

Does not work:
Address 3010:

CV17: 203 - 11001011

CV18: 194 - 11000010


Same bit pattern, but with bit 4 in CV17 low
Works OK:

Address 1986:

CV17: 199 - 11000111

CV18: 194 - 11000010


Same not working CV17 value, different CV18 value
Does not work:

Address 3034:

CV17: 203 - 11001011

CV18: 218 - 11011010


Different CV17 value, but still bit 4 set.
Does not work:

Address 3266:

CV17: 204 - 11001100

CV18: 194 - 11000010



Works OK:

Address 5314:

CV17: 212 - 11010100

CV18: 194 - 11000010



Works OK:

Address 9010:

CV17: 227 - 11100011

CV18: 050 - 00110010

[Trond]

Has no one been able to test this?  Or am I not making clear what the problem is?

[Trond]

I think I might have found the problem.

First, when I said bit 4 I was counting from 1.  I should probably have said bit 3, as it's more customary to count from 0 when talking about bits.


This was tested with version 2.19 that i found as a hex file in a post in this forum.  The download package contains the source code for version 2.18.  Is the source for v2.19 available anywhere?

I have studied the sourcecode of v2.18 and found that in the "chk_longadr:" section, starting on line 1164 it says:

chk_longadr:

btfss CV29,long_adr ; Is decoder using a long address?

goto exit_bank1 ; No

btfsc DATA1,3 ; 128-191

goto exit_bank1
The line btfsc DATA1,3 will make every address that has bit 3 set jump to "exit_bank1", which I think ends decoding.

I think this may have been meant as a check for values higher than 232, which are marked as "reserved" in the specification (http://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf).  But there will also be several valid mobile decoder addresses that also has bit 3 set, which is the problem I discovered.

I haven't tried removing this and compiling yet.  I would really like to get hold of v2.19 as to not reintroduce whatever bugs where fixed between 2.18 and 2.19.

[Paul Harman]

Here is V2.19.

I see the problem. It needs a bit of more thorough checking to only exclude 232-255. Comment is wrong too! The simple check on bit 3 is inadequate and catches a lot more than it should. It will either need a bit of arithmetic to check that value or a sequence of bit checking. Might be OK to just remove this check since the compare with stored address will fail further on anyway since it will not match the stored CV17 and CV18 values (if they are within the acceptable range).

Take a look at NMRA S-9.2.1 line 42

www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf

Attachments:

Ver2.19 Beta 4.zip (20.56 KB)

[Trond]

Thank you for the updated source.

I was thinking that, as you said, since it won't match CV17 and 18 there shouldn't be a problem just removing it.
If the stored CV17 and 18 doesn't contain a legal value you have probably gone out of your way to set it that way.

I think there is only two free program memory words left so the amount of checking you can do is a bit limited, unless you find something else to remove.
Maybe it's time to migrate to a PIC12F1840?

[Paul Harman]

I have written new code for the 12F683 and 16F684 for the function decoder because the higher speed allows a lot more functionality, but that is not open source so not available for download (you have to buy the PICs). I have rewritten the accessory code for 16F1825 and 16F1829 now (not 12F1840 because not enough code space), and again that is not open source so you can't download either unfortunately but you can buy PICs preprogrammed.

[tom]

Hi,

Sorry to resurrect an old thread, but I've just put together a prototype function decoder on a breadboard and I think I'm seeing the same issue as Trond reported. When set to certain long addresses (3010, 3034 and many others), the decoder is not responsive to any function commands, but other addresses work fine (eg 5314). In every case, if I set bit 3 in CV17 to 0, the decoder functions work, and if I set it to 1, they do not.

My setup:
- PIC12F629
- Programmed with PicKit3 and the PicKit3 programmer software, v 3.1.0.
- Using firmware Ver2.19 Beta 4 taken from this thread.
- Using function F2 connected to output pin GP2 (physical pin 5).
- Programming using DecoderPro (JMRI 4.2.0).
- Programming using a MERG CANCMD.
- Controlling using a MERG CANCMD + MERG booster, with a CANCAB heldheld for control.

Is there a more recent version of the firmware that contains a fix for this problem (if indeed this is the problem!)

Thanks,
Tom

[rayray]

Just a quick question for long address:
If I set a certain address on CV17 and CV18, is the decoder automatically recognized to be controlled in long address mode?
Do I need to adjust another CV to have the decoder run on long address?

[peteb]

You also have to set a bit in CV29, which controls whether the short or long address is used.

Best bet is to Google "CV29 calculator", this will take you to the 2mm association calculator for CV29. You can tick the boxes for what you want (including short or long address mode) and it works out the value to put in CV29.

Further down the page, there is also a CV18 and CV18 calculator, so you can enter the long address you want and it works out the CV values for you.