| View previous topic :: View next topic |
| Author |
Message |
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
| switch |
 Posted: Sat Aug 22, 2015 12:09 am |
 |
|
Hey,
Interesting thing I see - as Yoda said.
PCWHD 5.046 18F4620
I have:
int var, var1, var2;
| Code: | switch(var)
{
case 0x01:
switch(var1)
{
case 0x01;
//do something
break;
case 0x02;
switch(var2)
{
case 0x01;
printf("blah");
break;
case 0x02;
print("blah1");
break;
}
break;
}
break;
} |
Randomly the switch is missing cases from nested levels down.
No rules.
Are there any guides in regards to nested switches?
I have debugged the thing and it is just no rule why an when it will miss the case. Nesting is for a protocol so is big and long. Run by main loop no no int involved, etc.
Is it possible that int like RDA or SSP jumping in the middle of executing switch will break its execution?
Thnx
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sat Aug 22, 2015 1:54 pm |
|
|
Obvious thing is that the syntax is wrong on all the inner switch statements. Not surprising they don't work as expected...
; != : |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sun Aug 23, 2015 12:01 am |
|
|
hehe, lets pretend that I did type it correctly. Anything to share on the subject?
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sun Aug 23, 2015 5:48 am |
|
|
Seriously the cause almost certainly is a typing error somewhere.
Probably a break that you sometimes reach by a different route, that results in an early exit from an outer loop you don't expect.
Tidy your layout, and especially the use of indents, and comments, and possibly run the code through something like lint. I suspect you will find something. It is terrifyingly easy to miss a break, or accidentally hit the wrong one when operating with nested conditions like this.
| Code: |
switch(var)
{
case 0x01:
switch(var1)
{
case 0x01:
//do something
break; //var1 case 1
case 0x02:
switch(var2)
{
case 0x01:
printf("blah");
break;//var2 case 1
case 0x02:
print("blah1");
break;//var2 case2
}
break; //var 1 case 2
}
break;//var case 1
}
|
Consider making the inner switches 'inline' routines. This way the exact exit paths for each layer becomes easier to be confident about.
Generally, the other likelihood is actually something (using pointers/ arrays typically), actually overwriting one of the variables. |
|
|
ELCouz
Joined: 18 Jul 2007
Posts: 427
Location: Montreal,Quebec
|
|
| Posted: Sun Aug 23, 2015 6:47 am |
|
|
| Ttelmah wrote: | Obvious thing is that the syntax is wrong on all the inner switch statements. Not surprising they don't work as expected...
; != : |
I'm surprised that it did compile without any errors....
_________________
Regards,
Laurent
-----------
Here's my first visual theme for the CCS C Compiler. Enjoy! |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Tue Aug 25, 2015 1:42 am |
|
|
Code is way bigger than this example, I did type it by hand in browser. Sorry for a type.
I will double check all exits. Thnx 4 d tips.
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sat Aug 29, 2015 3:51 am |
|
|
So I have found the issue, what is happening my i2c bus somehow is doing a lie on one particular string I do send.
| Quote: | | send_to_i2c (0xA0, 0x03, 0x0F, 0x0C, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF); |
This however is read by another MCU as
0xA0, 0x03, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
So switch is spot on as such command does not exist.
So after long process of debugging finally I am seeing where is the problem.
This is odd. I do not have digital logger (need to make one) so I cannot tell if this is the error related to to i2c bus loading with some odd capacity or it is a problem with my code reading the data from i2c bus.
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sat Aug 29, 2015 1:06 pm |
|
|
Well done for finding it.
Without knowing how your I2C function sends and receives, difficult to know, but it is unlikely to be capacitance, since the problem appears with a byte sending four consecutive 1's.
.
There are a lot of errata on the MSSP on this chip. I remember having to use software mode to actually get I2C to work even remotely on these. There is an erratum where with multiple slaves, a slave will respond to it's address if sent as data, so if you have multiple slaves on the bus this would cause chaos. There is also a major problem when doing data reception in master mode. Timing is awful. I also had to apply the fix about controlling the I2C lines before enabling the peripheral. They say this only applies to some chips/systems but I had it on three different boards....
Seriously the I2C peripheral on these PIC's is one of the most buggy peripherals on any PIC. I'd really suggest not using it. If this is a master, use software I2C, if you are using a slave, then find an alternative chip....
 |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sat Aug 29, 2015 6:07 pm |
|
|
One master, one slave - both identical chips, then RTC and 2x EEPROM, temperature sensor.
Not much choice here, boards are made and going out. Beside I have got many of them out already and it works, I guess it is something to change in next PCB revision.
I post whatever I find in due time.
thnx.
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sun Aug 30, 2015 1:15 am |
|
|
It is a load and capacity on the bus, FF in continuous string creates charge on the bus and then corrupts the messages, it is enough to change to FE and the problem goes. So in the i2c handling I had to do controls as you said to deal with faulty stings and check each packet if it arrives and is processed correctly.
However the problem does not exist at all on RTC, EEPROM, Temperature sensor, so I tend to agree that the issue is in the chip itself.
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19552
|
|
| Posted: Sun Aug 30, 2015 2:01 am |
|
|
Try using a software master. Only take a second to try, and not as fast, but it fixed multiple problems for me....
Also question of the actual chip revision?. There were something like fourteen errata on the MSSP on earlier chips, while the latest revision massively reduces this. You speak about "many of them out already and it works", is it possible that these had a different silicon revision?. |
|
|
Linuxbuilders
Joined: 20 Mar 2010
Posts: 193
Location: Auckland NZ
|
|
| Posted: Sun Aug 30, 2015 4:07 am |
|
|
I will check, I have i2c problems from day one, was handling it by software before but not as well as I do now.
Once I have swapped FF with FE it is spot on, makes a mistake one in few hours. Before it was like every few messages. I flood it all the time so one in few hours is very good score.
chip 18F4620 -I/PT(e3) 1452EET.
I guess next PCB revision will have more focus on i2c bus so it is perfect 
But in general it is ok now, I guess error handling does the job.
I will need to scope it a bit more, if does crash on 2.2K when I try to measure it, on 1.8K is happy so the resistance is having big go here too.
_________________
Help "d" others and then you shell receive some help from "d" others. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
