CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

Modbus & ticker
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
greenbridge



Joined: 14 May 2018
Posts: 19

View user's profile Send private message Send e-mail

Modbus & ticker
PostPosted: Mon May 14, 2018 8:32 am     Reply with quote

hi,

I plan to use Modbus RTU and a ticker at the same time. When compiling the code I get following warning:
Quote:
>>> Warning 225 "C:\Program Files (x86)\PICC\Drivers\modbus_phy_layer_rtu.c" Line 25(1,1): Duplicate #define TICKS_PER_SECOND has been redefined
despite the fact that the Modbus and the ticker are using different timers.
All Modbus files are unaltered, as shipped from CCS.
Does this means that the modbus and the ticker code are incompatible?
My main code is as follows:


Last edited by greenbridge on Thu Mar 25, 2021 3:32 am; edited 1 time in total
RF_Developer



Joined: 07 Feb 2011
Posts: 839

View user's profile Send private message

Re: Modbus & ticker
PostPosted: Mon May 14, 2018 9:32 am     Reply with quote

greenbridge wrote:
When compiling the code I get following warning:
Quote:
>>> Warning 225 "C:\Program Files (x86)\PICC\Drivers\modbus_phy_layer_rtu.c" Line 25(1,1): Duplicate #define TICKS_PER_SECOND has been redefined
despite the fact that the Modbus and the ticker are using different timers.

Does this means that the modbus and the ticker code are incompatible?


In a word, yes. That does not mean they cannot be used, it just means you will have to modify one, or both, though that's not the best way to go.

The CCS drivers are essentially "get you going" (almost) standalone example code and not full plug-and-play drivers. They are often not capable of being used with other "drivers". without some modification.

There may be conflicts when used with others that we, the users, will have to sort out for ourselves. For example anything that uses SPI may use the old setup_spi() routines or the newer #use SPI() directives. They will also not, out of the box, be able to use one SPI interface to drive several different devices. Sorting that out is the user's job and will differ from application to application and be hardware and system specific.

In this case you've discovered that the same name, TICKS_PER_SECOND, is used for different, incompatible timing in the two "drivers". You will have to sort out how to make them compatible for your hardware. That may be as simple as renaming one, it ay be much more complicated than that. There is no guarantee that any two or more drivers will have no conflicts: its up to you, the developer, to sort it out.

Of course, its advisable to not modify the CCS drivers unless you absolutely have to, but sometimes its unavoidable. If you do modify, modify a copy in your own project workspace, leaving the CCS source code unchanged.

Just be thankful it's not the TCP/IP stack. The CCS version is a partial port, with very limited functionality, of an older version of the Microchip stack. To get many functions to work requires a lot of changes and time and effort.
Ttelmah



Joined: 11 Mar 2010
Posts: 19552

View user's profile Send private message

PostPosted: Mon May 14, 2018 11:26 am     Reply with quote

Just change 'TICKS_PER_SECOND' in the ticker code to 'TICK_TICKS_PER_SECOND'. Where it is defined and where it is used. A total of a couple of locations.

Also comment:

ADC_CLOCK_INTERNAL, is _not_ recommended if the chip is being clocked above 1MHz. Correct this. The data sheet shows the recommended clock.
greenbridge



Joined: 14 May 2018
Posts: 19

View user's profile Send private message Send e-mail

Modbus communication stop
PostPosted: Wed Mar 03, 2021 2:25 am     Reply with quote

Hi guys,

Can point anything in the code below that can cause communication stop or the PIC to stop executing the code:


Last edited by greenbridge on Thu Mar 25, 2021 3:32 am; edited 1 time in total
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Wed Mar 03, 2021 3:11 am     Reply with quote

Code:
while (TRUE) {
    gv_check();                                                                         
    adc_read();   
    status_check();
    if (modbus_kbhit()) {                                                                 
      restart_wdt();
      delay_us(50);                                                                                             

If you don't get a modbus message, you will get a watchdog timeout.
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Mar 03, 2021 6:44 am     Reply with quote

WDT is never needed until product is ready for the client. Only then should you enable it with a timeout that has been carefully chosen based upon the actual program running.
If you have it enabled during 'R&D' stage, you'll have to update the timeout value as you change the program.
greenbridge



Joined: 14 May 2018
Posts: 19

View user's profile Send private message Send e-mail

Modbus communication stop
PostPosted: Tue Mar 16, 2021 9:43 am     Reply with quote

It seems like large chunks of the program memory are being deleted after some time (hours). I am not sure what causes this. Could it be RF or an error in virtual eeprom write functions.?

Any ideas are welcome.
The code is the same as earlier in this thread.
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Mar 16, 2021 9:54 am     Reply with quote

How was the PIC programmed ?
Only one PIC with this problem ?
Which 'chunks of memory'
'corrupted' memory, is it all 0xFF or 'random' data ?
Any bootloader program in PIC ?
Can PC reprogram PIC memory ?
Any address checking done BEFORE writing to the 'virtual EEPROM' ?
Any 'cast' values NOT correct ?
WDT enabled ?
Any variables NOT set upon powerup ? (RAM is RANDOM....)

There's ten possibles.....
greenbridge



Joined: 14 May 2018
Posts: 19

View user's profile Send private message Send e-mail

PostPosted: Tue Mar 16, 2021 10:08 am     Reply with quote

Quote:
How was the PIC programmed ?

ICD-U64

Quote:
Only one PIC with this problem ?

Multiple devices installed in identical units (refrigerant compressors). Some working without problems, some having the problem described.

Quote:
Which 'chunks of memory'
'corrupted' memory, is it all 0xFF or 'random' data ?

Intel hex dump from upload:
From :101720 to :101FF0 - Filled with FF3
From :1029F0 to :107F80 - Filled with FF3

Quote:
Any bootloader program in PIC ?
No

Quote:
Can PC reprogram PIC memory ?
Yes

Quote:
Any address checking done BEFORE writing to the 'virtual EEPROM' ?

Presumably (I might be terribly wrong here) done by virtual eeprom write functions.

Quote:
Any 'cast' values NOT correct ?

Not what I can see (uint to bytes before virtual eeprom write).

Quote:
WDT enabled ?

Yes (256 ms)

Quote:
Any variables NOT set upon powerup ?(RAM is RANDOM....)
See the previous code.
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Mar 16, 2021 11:13 am     Reply with quote

RF won't be a problem if PIC is in a proper metal box, grounded, with all external wiring 'filtered', including the power supply.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

Re: Modbus communication stop
PostPosted: Tue Mar 16, 2021 12:44 pm     Reply with quote

greenbridge wrote:
Hi guys,

Can point anything in the code below that can cause communication stop or the PIC to stop executing the code:

#include <16F1518.h>

#device ADC = 10
#device *= 16
#fuses NOMCLR, WDT

#FUSES WDT //Watch Dog Timer
#FUSES NOMCLR //Master Clear pin disabled
#FUSES NOBROWNOUT //No brownout reset
#FUSES NOIESO //Internal External Switch Over mode disabled
#FUSES NOFCMEN //Fail-safe clock monitor enabled
#FUSES NOWRT //Program memory not write protected
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOLVP //No Low Voltage Programming on B3(PIC16) or B5(PIC18)

//#use delay(internal=8Mhz)
#use delay(clock=8M, crystal)

#include <virtual_eeprom.c>

1. Remove the NOBROWNOUT fuse and enable Brownout and set it to
the highest allowed voltage, which is done with:
Code:
#fuses BORV25

2. Get rid of the virtual eeprom. I personally would never use Flash as
a substitute for eeprom in any project, but especially not in an electrically
noisy industrial environment. Use a real i2c eeprom.

3. We don't know anything about your board layout, but hopefully it's a
four layer board with layer 2 for Ground and layer 3 for power.
Layers 1 and 2 are for signals.

4. Every chip must have a 100 nF ceramic cap from each power pin to ground.

5. The power supply must be robust and well filtered.
greenbridge



Joined: 14 May 2018
Posts: 19

View user's profile Send private message Send e-mail

PostPosted: Tue Mar 16, 2021 4:04 pm     Reply with quote

Hi.

I added BORV25 without success (My bad overseeing this, anyway).

All of the chips on the PCB are decoupled with 100 nF capacitors.
Power supply has a proper common mode choke filtering (tested in an EMC lab).

I will try to replace the microcontroller with some pin compatible alternative with separate data eeprom.

Thanks for your good advices.
temtronic



Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Tue Mar 16, 2021 4:43 pm     Reply with quote

Do you need a RTC ? Depending on how much EEPROM you need, it might be possible to buy one of the 'modules' that has both a Dallas DS3231 RTC and Atmel 24l32 EEPROM.
I know usually 'space is tight' but the DS RTC is a very accurate clock. I use it to give my PICs a 1HZ interrupt (used to update the LCD) as well as 'trigger' the DS18B20 temp sensors.
At $2 a unit,simple I2C interface and well, they always work..... I don't believe in the 'sub,sub micro ultra mini packages'
Maybe an option ?
greenbridge



Joined: 14 May 2018
Posts: 19

View user's profile Send private message Send e-mail

PostPosted: Wed Mar 17, 2021 12:16 am     Reply with quote

RTC is not necessary. I prefer the pin compatible PIC to avoid the changes in the hardware design.
Ttelmah



Joined: 11 Mar 2010
Posts: 19552

View user's profile Send private message

PostPosted: Wed Mar 17, 2021 2:20 am     Reply with quote

Quote:

Presumably (I might be terribly wrong here) done by virtual eeprom write functions.


Simple answer. Not really.
Problem is that the VE functions, depend on variables set in the init.
If anything corrupts these values, the 'write' can occur to any address
in the memory....
The variables are in the _g_VE structure.
Problem is that if any external effect corrupts the chip RAM, then 'anything
can happen'. It does sound as if something may be spiking the chip. Question
is 'what'....
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group