How long does CCS tech support normaly take to fix things ?

[nurquhar]

I have submitted tech support request to CCS for a problem with my new Mach X programmer. See http://www.ccsinfo.com/forum/viewtopic.php?t=28002

How long is reasnable amount of time for them to come with a fix ? What are your experiences ?

[ckielstra]

Problems can be fixed from within a couple of days to several weeks. Problem then is that you'll have to wait for the next version to be released to get access to the fix. New versions are released depending on number and severity of other bugs fixed and on some unspecified other variables like amount of money sent to a certain bank account, etc.

Now with version 4 out all the effort will go into making that a stable release. From past experience this will take at least 6 months. I reported a bug in v3.249 several months ago and got confirmation of the problem being solved in the next release. I'm still hoping a v3.250 version will be released as I don't want to migrate to v4 until it has proven to be stable for several months.

[Ttelmah]

I'm not sure that the problem here is with MachX. There is something wrong with the declaration being generated by the compiler. When you generate a constant, the prgram to read it is also attached in the memory area. For the example you give, the configuration line in the hex file, should be accessing the data _after_ this program, which would start at FF4, not FF1. I generated a demo test, with the serialise configured as I normally do it:

[nurquhar]

Dear Ttelmah

Its interesting that it worked for you ! I compiled your code with my 3.249 pcm and goto exactly the same hex file you posted, reassuring to know ! However to be sure I cut-pasted your hex code from the posting into a hex file tried it in my "Barnd New" MachX (Device Programmer V1.89). I put in a brand new PIC16F648A into the ZIF socket, checked that device was PIC16F648A and the green dot in the ZIF socket option and hit the "Burn Chip". I also checked the details in "Serial numbering" button and it all looked good to me, ie green tick in use automatic and address 4084 (FF4) and length 4, binary option, inc no saved in other file, and the correct serial and logs file entrys.

I got verification error at address FF4 where Actual was 3400 and Expected was 340F (16 now in serials.txt). Just to check I read the chip back with my ICD2 and yes FF4 = 3400 (ie RETLW 0).

I tried again with another brand new 16F648A, same problem.

I would hazard a guess that the machx actualy tried to put the 340F at some random location out of Prog EEPROM range. I looked for the RETLW's in some other Prog location but could not find any. With my code the random location it chose to put the ROM_UID in was within Prog EEPROM range and so the verification succeeded, all be it the wrong place to put it.

Which version of MachX do you have ? Did you read the chip back again to check ?

Oh, the reason my original code loaded the int32 at FF1 instead of FF4 as in your test was due to the large size of my code and thus the call to get the ROM_UID was in the same bank as the routine and thus the BSF PCLATH instructions were deemed not necessary by the compiler and it saved the use of three words.


Here is my hex code which results in 0x8CA getting over written by the ROM_UID code when programmed with the MachX. If you can try it in your programmer and see where the ROM_UID ends up after you read the chip back again?

[Ttelmah]

I am currently running 1.78, which fixed a problem I had previously suffered from with the Mach-X, rather than the latter 1.88. I wonder if the latter version actually creates the problem!...

Best Wishes

[nurquhar]

I will try and contact CCS Tech Support to get a retro grade version of MachX software, ie V1.78. Hopefully they will see then sense in this.

[Ttelmah]

As another comment, when you originally contacted them, you should have received an automated acknowledgement, with a 'reference' number. You can email using this reference number, to find out what is going on. While not advisable after only a day or two, after several weeks, it is worth doing this, to see what on earth is going on!...

Best Wishes

[nurquhar]

Tech support have offered to email me the next release which is due out tommorow. They seem to be "hoping" this will fix to the problem rather than "knowing" it will be a fix. Will let you know when I get V1.90.

[nurquhar]

As suspected MachX V1.90 does not fix the #serialise programming issue. After more phone calls and emails to CCS support they now seem to accepted the problem does exist.

However they have now given it new trouble ticket no 3 weeks after I first reported it. So have I lost 3 weeks while the first trouble ticket sat in a que waiting for somebody to look at it ?

[nurquhar]

Dear Ttelmah

Can you post or email the MachX V1.78 for me to try ?

[nurquhar]

Fix found !

See http://www.ccsinfo.com/forum/viewtopic.php?p=69245#69245

[Ttelmah]

Sorry, I missed the earlier post asking for the older file. Hurrah!. You have a fix. Interesting, they have changed a DLL. I wonder if I may actually have a changed version (I was having a problem with MachX, and they sent me various fixes at points for my problem, and eventually it all worked).
Glad you have it working now.

Best Wishes

[nurquhar]

Dear Ttelmah
Using guess work I think ccsicdu.dll is part of the driver interface to the MachX, possibly the CCS ICD debuggers too. The dll version given to me has an older version number, 1.0.0. Are you asking to try this new dll to fix your problem ? If so you will need give me a means of sending it to you.