Bugs (maybe fix), and suugestiong for Flowcode5 for DsPIC.

Moderator: Benj

Post Reply
Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Bugs (maybe fix), and suugestiong for Flowcode5 for DsPIC.

Post by Mikat »

Hi.

There is bug in the DsPIC internal CAN component, then component can never set the baudrate,rx mask or filters, because the reqop config mode value is wrong..
The REQOP bits are CiCTRL 10-8 and the config mode is 100, so when requestin config mode, the CiCTRL register value should be 0b10000000000 = 0x0400...
But the define value is 0x80.
I mean this:

Code: Select all

//CANCTRL
#define REQOP_CONFIG		0x80
#define REQOP_LISTEN		0x60
#define REQOP_LOOPBACK		0x40
#define REQOP_SLEEP		0x20
#define REQOP_NORMAL		0x00
All of those are wrong, except the reqop normal value...
But maybe better solution is write only the REQOP bits, in the CiCTRL register, that way entering or exit in the config mode don't write other bits in the CiCTRL register (like the CANCKS), which should be set if fcan is 30MHz or higher...
Here is the way what I mean:

Code: Select all


#define REQOP_CONFIG		0x04  //changed by mikat

//configure CAN I/O - ds30F??

		// Request config mode.
		C1CTRLbits.REQOP = REQOP_CONFIG; //changed by mikat

		// Wait till desired mode is set.
		while( C1CTRLbits.OPMODE != 0x04 ); //changed by mikat

		// Now set the baud rate.

		//Setup the CAN comms Masks and Filters
	
		// Request normal mode.
		C1CTRLbits.REQOP = REQOP_NORMAL; //changed by mikat

		// Wait till desired mode is set.
		while( C1CTRLbits.OPMODE != 0x00 ); //changed by mikat
Instead of this

Code: Select all

//configure CAN I/O - ds30F??

		// Request config mode.
		C1CTRL = REQOP_CONFIG;

		// Wait till desired mode is set.
		while( (C1CTRL & CAN_OP_MODE_BITS) != 0x80 );

		// Now set the baud rate.


		//Setup the CAN comms Masks and Filters
		
		// Request normal mode.
		C1CTRL = REQOP_NORMAL;

		// Wait till desired mode is set.
		while( (C1CTRL & CAN_OP_MODE_BITS) != 0x00 );
.
The Flowcode also gives warning at the unconnected chipselect pin, when the internal can is used..
The SPI component gives compiler error, if the DAC enable and NVM enable pins are unconnected, could there be not used option, that those don't "waste" i/o pins, when are unused?
The onewire component seems to have bug, which is included both, the 8 and 16 bit version, the scanbur or devicecount function don't work, so the code don't get the device rom address..
Btw. is there any plans at the internal can at the 33 and 24f devices?
I'll try to make code for those chips internal can, but then I hit the wall, the tx and rx buffers goes via DMA transfer, and that is too complicated to my skill...

Mika

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Benj »

Cheers Mika,

I will have a look and get back to you.

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Benj »

Hello Mika,

I believe I have fixed all the internal CAN bugs you mentioned. As for the undefined pin warning I believe this can be ignored for now as I don't have access to the component source which specifies the number of pins required. Hopefully this is a minor change we can make later. Again the SPI component has basically the same issue. If you connect the pin in the connections manager then the warnings or compilation errors will go away and if your not using the macros that use those pins then you should be free to use the pins elsewhere.
PIC16BIT_CAL_CAN.c
(24.13 KiB) Downloaded 382 times
I have a plan to implement CAN for the dsPIC33 and the PIC24 ranges of devices but this will probably have to wait until v6 is released as we are changing the way components work in Flowcode. DMA transfer is not too bad but example code helps a lot :)

As for the 1 wire bug. Can you confirm that this bug was not present in v4? I will look into this but don't currently have any 1 wire devices for testing. Hopefully I will be able to get my hands on some shortly. Any ideas as to what has gone wrong?

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Benj wrote: As for the 1 wire bug. Can you confirm that this bug was not present in v4? I will look into this but don't currently have any 1 wire devices for testing. Hopefully I will be able to get my hands on some shortly. Any ideas as to what has gone wrong?
The CAN code seems ok..
I'll try to test it asap...
Any example code for DMA??
What comes the onewire, I can confirm that it works on 8bit version of FC4, but if I remember right, it doesn't work at dspic version of FC4... I try compare those codes tonight, maybe I find something...
One thing is that the dspic is quite lot faster at the i/o ops, at least at 100MHz clock... But the communication seems to be ok, when I check it at logic analyzer...

Mika

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Good morning Ben.

Try to investigate the onewire problem bit better at last night, but very little result...
The comm seems to not work, not even the hw level, logic analyzer don't understand the sensor responce..
All I managed to dig out is that it seems that the code gives error on the scanbus function, at the get next id macro, at this point:

Code: Select all

else if (val0 && val1) // 1 et 1 impossible
{
return 2;
}
The scanbus macro returns value 2, so I think it's that error...
Try look more when I have some extra time.

One other thing was that there was somewhere discussion about the CAN RXint at the 30F series chip...
Here is the workin RXint code at the 30F, feel free to use if needed..
Enable code:

Code: Select all

IEC1bits.C1IE = 1; // enable can it
C1INTEbits.RX1IE = 1; //enable rx1 int
C1INTEbits.RX0IE = 1; //enable rx0 int
And handler code:

Code: Select all

void _ISR _C1Interrupt(void)
{
if (C1INTFbits.RX1IF)
{
C1INTFbits.RX1IF =0; // clear rx1 int flag
IFS1bits.C1IF = 0; // clear can interrupt flag
FCM_canrx_1(); // call rx1 macro
}
if (C1INTFbits.RX0IF)
{
C1INTFbits.RX0IF =0; // clear rx0 int flag
IFS1bits.C1IF = 0; // clear can interrupt flag
FCM_canrx0(); // call rx0 macro
}
}
As you can see, the int code isn't so straight forward as usually, after the int is triggered, the buffers int flags need to be checked, to decide which one of the buffers has the message.. So there might need to call two different macros, if the macro is different at different buffers..

Mika

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Hi.

There is the scanbus picture for logic analyzer, upper is fc4 8 bit, which works ok, lower is fc5 for 16 bit, not working...
Both captures start at the same point, end of the searchrom command.
If you look between markers 1 and 2, there is some diffrence, but the transmission shoud be same, because it seems to be familycode section (16 at ds1820).
ow scanbus compare med.JPG
(235.02 KiB) Downloaded 2791 times
Notice that the scale is not exactly same...

Mika

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Good morning.
There is better capture for logic analyzer, the scale is same, and the timing are almos equal.
I tweaked the timings at the FC5 16bit as close the FC4 8 bit as the delays allow, so the problem is not the timings...
The working FC4 8 bit is the lower capture.. I swithc the sensord, to confirm that the problem isn't the sensor and let you know then..
At that capture, should be quite easy compare the code where thing goes wrong (between the t1 and t2 timing markers)...
Yep, can confirm that the problem ain't the sensor...

T:Mika
Scanbus compare matched.JPG
(227.27 KiB) Downloaded 2772 times

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Benj »

Hi Mika,

Right I'm currently comparing the v5 and v4 PIC C code and there really isn't a lot of difference between the two.

Did you manage to find out if the v4 dsPIC code worked?

Also do you have v5 for PIC to test if this is ok?

Can you recommend any 1 wire devices for me to buy in and use as test platforms as I have bought them before and always found them to be really unreliable.

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Benj wrote:Hi Mika,

Right I'm currently comparing the v5 and v4 PIC C code and there really isn't a lot of difference between the two.

Did you manage to find out if the v4 dsPIC code worked?

Also do you have v5 for PIC to test if this is ok?

Can you recommend any 1 wire devices for me to buy in and use as test platforms as I have bought them before and always found them to be really unreliable.
Yep, I compared them too, didn't find anything, I'll try more maybe this evening, try to understand onewire "init" protocol..
No, if I don't remember totally wrong, the FC4 dspic don't work..
No, I don't have the ver5 8 bit,only 16bit, if you give one me I can test :lol: .
I don't know (haven't used) any other onewire devices than ds temp sensors.. Actually, I don't have very much problems with those sensors, only in the "noisy" environment they are quite tricky, need quite small pu resistor, serial resistor and maybe some protection and caps..

Mika

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Hi Ben.

Now I think that I understand the "init" protocol of onewire, but the Dallas document was quite confusing..
So the slave device sends first the bit,then same bit inverted, and then master responds at the bit which was first send (not inverted), but if the bus has devices which sends 01 and 10 the bits are 00 (bus is 0 dominant), and then master chooses the device which will continue, and sends a correct bit..
If you look at the logic data above you see that the slave send bit starts at the +0.7ms, and the slave sends 10, the inverted byte (0) is just before timing marker 1, BUT then, the master should send 1, and it sends it at the lower capture, just at the point where is the [16], but the upper capture (which is at FC5), the master send 0!! So there is the error, now when the master responce don't match the slave bit, the slave goes at the "sleep" mode, and don't respond anythin else than busreset, so thats why the code gives error 2, the bus is high all the read time...
But I don't know why that responce is wrong, continue investigatin (it would be nice to see if the 8bit version gives same error at the same point, can anybody scan it with logic analyzer?)...


Mika

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Good morning.
Banged my head to the wall couple of hours last night, with that problem :x .
I just can't figure out why that problem occurs. When the result of two readings is 10 or 01, the code just should sent the val0 after the reception, and that it will do if I manually set the values at 10. Disabled the 00 and 11 conflict part at the code, but the error in logic data remains.
Ben do you have the logic analyzer to capture scanbus at the 8bit version of FC5 (there is other topic, where somebody says that the 8bit version of FC5 have problem too)?
Because I really like to see what happens at different PIC, at the moment I am not sure is this sw or hw problem (and only surely working hw I have is the 18F4680), my problem is that I have only 30F6012A boards at the moment, and all my 16bit PICs are smd devices, for 8 bit I have like 10 different DIP 40 PICs...

Mika

User avatar
Benj
Matrix Staff
Posts: 15312
Joined: Mon Oct 16, 2006 10:48 am
Location: Matrix TS Ltd
Has thanked: 4803 times
Been thanked: 4314 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Benj »

Hi Mika,

I am in the process of ordering some 1 wire sensors to have a play with. In the mean time I have sent you a PM with a 30 day v5 PIC trial key so you can install and test the 8-bit software. with v5 all the variants use the same code base so if we get it fixed for one then it should sort itself out in the other versions.

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Hi Ben.
The 8 bit version of FC5 don't have that problem.. It might have some issues with multiple sensor, but I was mixed the DS1820 and 18B20, but that actually should work, but no matter what sensor number I was reading, it always sends sama rom ID.. Need to investigate more... Yep, the code reads just the first sensor, no matter what is in the oo read device count box...
But the error in scanbus function seems to be problem with DsPic or my hw (I have tested 3 diffrent pin at my hw..)


Mika

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Ok, been away for a while, now back to the problem.
At the 8bit version of FC5 there is something wrong with reading the first sensor dev id, tested it to printing the dev id array to display.
If I have 3 sensor, the dev id goes id 0 = 220,0,0,0,0,0,0,0 id1 = 40,67,30,223,3,0,0,147 id2 = 40,243,156,205,1,0,0,172 and if I remove the first sensor (it's 1820, so the first byte should be 16, the other 2 sensor are 18b20, so the family id is 40 as the firs byte of romcode shows) the dev id goes like this id 0 = 220,0,0,0,0,0,0,0 id1 = 40,243,156,205,1,0,0,172, so the firs sensor romcode is always 220,0,0,0,0,0,0,0..

Mika

Mikat
Posts: 258
Joined: Wed Nov 29, 2006 6:32 pm
Location: Finland
Has thanked: 7 times
Been thanked: 36 times
Contact:

Re: Bugs (maybe fix), and suugestiong for Flowcode5 for DsPI

Post by Mikat »

Ok, found at least one bug..
In the FC5 8bit there is error in the read device macro..
This:

Code: Select all

%a_oo_DevID[loper] = %a_oo_id[loper+(count<<3)];
should be like this:

Code: Select all

%a_oo_id[loper] = %a_oo_DevID[loper+(count<<3)];
.
After that the code seems to work ok, but I am not sure do I have 2 broken sensors, they don't seem respond at all, the 2 first byte is always 80,5...
But at least after that fix, the code calls right sensor, and get the romid:s right...

Mika

Post Reply