| View previous topic :: View next topic |
| Author |
Message |
greenbridge
Joined: 14 May 2018
Posts: 19
|
| Modbus & ticker |
 Posted: Mon May 14, 2018 8:32 am |
 |
|
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
|
| Re: Modbus & ticker |
| Posted: Mon May 14, 2018 9:32 am |
|
|
| 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: 19543
|
|
| Posted: Mon May 14, 2018 11:26 am |
|
|
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
|
| Modbus communication stop |
| Posted: Wed Mar 03, 2021 2:25 am |
|
|
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
|
|
| Posted: Wed Mar 03, 2021 3:11 am |
|
|
| 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: 9244
Location: Greensville,Ontario
|
|
| Posted: Wed Mar 03, 2021 6:44 am |
|
|
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
|
| Modbus communication stop |
| Posted: Tue Mar 16, 2021 9:43 am |
|
|
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: 9244
Location: Greensville,Ontario
|
|
| Posted: Tue Mar 16, 2021 9:54 am |
|
|
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
|
|
| Posted: Tue Mar 16, 2021 10:08 am |
|
|
| 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).
Yes (256 ms)
| Quote: | | Any variables NOT set upon powerup ?(RAM is RANDOM....) |
See the previous code. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9244
Location: Greensville,Ontario
|
|
| Posted: Tue Mar 16, 2021 11:13 am |
|
|
| 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
|
| Re: Modbus communication stop |
| Posted: Tue Mar 16, 2021 12:44 pm |
|
|
| 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:
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
|
|
| Posted: Tue Mar 16, 2021 4:04 pm |
|
|
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: 9244
Location: Greensville,Ontario
|
|
| Posted: Tue Mar 16, 2021 4:43 pm |
|
|
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
|
|
| Posted: Wed Mar 17, 2021 12:16 am |
|
|
| RTC is not necessary. I prefer the pin compatible PIC to avoid the changes in the hardware design. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19543
|
|
| Posted: Wed Mar 17, 2021 2:20 am |
|
|
| 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'.... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
