18F4550 with WLAN_ESP8266 doesn't work

[MJU]

I've made the same program in FC V6 and V7.

When I look into the generated C-code I find differences in the generated code.
In the UART stuff I find these differences:

/*========================================================================*\
Use :cal_uart1
:Variabele declaratie
:Macro functie declaraties.
\*========================================================================*/
V7 = #define MX_UART_CTS_PORT_1 portb
V6 = #define MX_UART_CTS_PORT_1 portc

V7 = #define MX_UART_RTS_TRIS_1 trisb
V6 = #define MX_UART_RTS_TRIS_1 trisc

V7 = #define MX_UART_CTS_TRIS_1 trisb
V6 = #define MX_UART_CTS_TRIS_1 trisc

V7 = #define MX_UART_CTS_PIN_1 (3)
V6 = #define MX_UART_CTS_PIN_1 (5)

Maybe this is not the problem, but the fact is that the LCD is connected to the B-port, and the code in the Flowcode 7 some references go to port B makes me wonder.
Could this be something?

Can I edit the V7 C-code in this manner that I can test it? How can I flash the changed C-code to the chip?

I really hope this is the problem, and can be solved.
I've waisted already too much time searching for the solution..

Can you confirm that this hasn't do anything with it?

There are in FC7 differences in the way the UART initialisation is done.
Some UART pins point to port B where they should point to port C....

[LeighM]

They probably will cause an issue, particularly if flow control is on, try this again ...

Try the component debugger window and expose component tree tickbox, this will let you go down through the properties of nested components.
The one you're looking for is the CAL UART.
Check that the flow control property is set to off.

But also change the flow control properties away from port B

btw.
Regarding my previous post, could you just confirm that the current issue is that the display does not work when the WLAN initialise is in the Flowchart?
Did moving the Interrupt make any difference?
Sorry, I can understand your frustration, but the more specific information you give us the quicker we can help.

[MJU]

With the ESP initialised

20170518_123651.jpg (150.47 KiB) Viewed 8206 times

They probably will cause an issue, particularly if flow control is on, try this again ...

Try the component debugger window and expose component tree tickbox, this will let you go down through the properties of nested components.
The one you're looking for is the CAL UART.
Check that the flow control property is set to off.

But also change the flow control properties away from port B

btw.
Regarding my previous post, could you just confirm that the current issue is that the display does not work when the WLAN initialise is in the Flowchart?
Did moving the Interrupt make any difference?
Sorry, I can understand your frustration, but the more specific information you give us the quicker we can help.

With the initialisation macro:

With the ESP initialised

20170518_123651.jpg (150.47 KiB) Viewed 8206 times

Without:

With the ESP initialised

20170518_123651.jpg (150.47 KiB) Viewed 8206 times

[MJU]

The properties:

Nieuw-2.jpg (65.28 KiB) Viewed 8206 times

Nieuw-3.jpg (79.33 KiB) Viewed 8206 times

[MJU]

They probably will cause an issue, particularly if flow control is on, try this again ...

Try the component debugger window and expose component tree tickbox, this will let you go down through the properties of nested components.
The one you're looking for is the CAL UART.
Check that the flow control property is set to off.

But also change the flow control properties away from port B

btw.
Regarding my previous post, could you just confirm that the current issue is that the display does not work when the WLAN initialise is in the Flowchart?
Did moving the Interrupt make any difference?
Sorry, I can understand your frustration, but the more specific information you give us the quicker we can help.

I deleted the interrupt macro in the file and it works just like when I started the post..
The LCD still doesn't work even after removing the interrupt

[LeighM]

Thanks for the images.
I presume that the property changes have now fixed the differences with RTS/CTS on PORTB, between V6 and V7 C code?
I cannot see any reason for what is happening.

[MJU]

Thanks for the images.
I presume that the property changes have now fixed the differences with RTS/CTS on PORTB, between V6 and V7 C code?
I cannot see any reason for what is happening.

I don't know what you mean by this.

A few weeks ago, after a long search I decided to make the same program in Flowcode 6 and 7 and look into the generated C-code.
In the UART properties I found that the FC7 component had different code than the FC6 C-code.

My questions:
- Is this possibly the reason the ESP component makes the LCD not to work?
- Because I've never seen the extended properties for any component, I've never altered it, why does it write different pins for the UART in the generated C-code?
- Most important: how can I make this thing to work (even if it is only with a temporary change in the code)?

For now I'm not looking for a working component, but rather a workaround so I can start using tha ESP with FC7..
(in FC I worked with this component and it worked)

[LeighM]

In the images that you posted of the properties, it looks like you have successfully changed the PORTB to PORTC
So my question was, is the C code now fixed? i.e. before you had ..

Code: Select all

V7 = #define MX_UART_CTS_PORT_1 portb
V6 = #define MX_UART_CTS_PORT_1 portc

Does the V7 generated C code now have portc too?

If not, this might still be the cause of the issue.

[MJU]

At this moment it looks like this:

#define MX_UART_TX_TRIS_1 trisc
#define MX_UART_REF1
#define MX_UART_RTS_PIN_1 (4)
#define MX_UART_DBITS_1 (8)
#define MX_UART_RETURN_1 (0)
#define MX_UART_RX_PORT_1 portc
#define MX_UART_RTS_PORT_1 portc
#define MX_UART_ECHO_1 (0)
#define MX_UART_FLOWEN_1 (0)
#define MX_UART_CTS_PORT_1 portc
#define MX_UART_TX_PIN_1 (6)
#define MX_UART_RX_TRIS_1 trisc
#define MX_UART_RTS_TRIS_1 trisc
#define MX_UART_BAUD_1 (115200)
#define MX_UART_TX_PORT_1 portc
#define MX_UART_RX_PIN_1 (7)
#define MX_UART_CTS_TRIS_1 trisc
#define MX_UART_CHANNEL_1 (1)
#define MX_UART_CTS_PIN_1 (5)
#define MX_UART_INT_1 (1)

[johnsondav]

Hi MJU

I apologise if I have got this wrong, but if you are using the file 'Flowcode2.fcfx' which you posted earlier, then according to the build setup, my configuration show this:

Flowcode2 Port B.jpg

(126.25 KiB) Downloaded 4531 times

The port B is set to an analog input configuration, instead of Digital. Might be worth checking your configuration settings.

Regards
Dave

[Benj]

The PortB as analogue config settings shouldn't matter the start of main should re-configure the pins to digital mode anyway. Good suggestion though.


When programming are you getting a message like this?

1: Flash memory not verified - may be due to code protect

I've just tried a 18F4455 here with your program and config settings and that is what I'm getting though the chip or board I'm using might have a problem.

The LCD shows black squares on the first 6 characters of the top line, then I get a 0 character after the ESP initialise.

I tried programming again with a PICkit and that is working correctly both with and without the initialise macro in the program. So maybe the programming is what is causing the problems you're seeing rather than the firmware itself.


On a side note, I have noticed that your RAM usage with the ESP component is quite large.

Look at the Receive buffer and Scan buffer properties. For an 8-bit PIC device I would recommend keeping these below 256 bytes.

[MJU]

The PortB as analogue config settings shouldn't matter the start of main should re-configure the pins to digital mode anyway. Good suggestion though.


When programming are you getting a message like this?

1: Flash memory not verified - may be due to code protect

I've just tried a 18F4455 here with your program and config settings and that is what I'm getting though the chip or board I'm using might have a problem.

The LCD shows black squares on the first 6 characters of the top line, then I get a 0 character after the ESP initialise.

I tried programming again with a PICkit and that is working correctly both with and without the initialise macro in the program. So maybe the programming is what is causing the problems you're seeing rather than the firmware itself.


On a side note, I have noticed that your RAM usage with the ESP component is quite large.

Look at the Receive buffer and Scan buffer properties. For an 8-bit PIC device I would recommend keeping these below 256 bytes.

I have changed the Receive and Scan Buffer < 256bytes.

[MJU]

The PortB as analogue config settings shouldn't matter the start of main should re-configure the pins to digital mode anyway. Good suggestion though.


When programming are you getting a message like this?

1: Flash memory not verified - may be due to code protect

I've just tried a 18F4455 here with your program and config settings and that is what I'm getting though the chip or board I'm using might have a problem.

The LCD shows black squares on the first 6 characters of the top line, then I get a 0 character after the ESP initialise.

I tried programming again with a PICkit and that is working correctly both with and without the initialise macro in the program. So maybe the programming is what is causing the problems you're seeing rather than the firmware itself.


On a side note, I have noticed that your RAM usage with the ESP component is quite large.

Look at the Receive buffer and Scan buffer properties. For an 8-bit PIC device I would recommend keeping these below 256 bytes.

Finally it works.. But I can't seem to find the proper settings for the PICkit programmer.
I used an old PPP.exe and... it works!
Finally

Is it possible to post working settings for PICkit in V7?

[Benj]

Hello,

Glad it's working for you now.

PICkit settings can be found here: https://www.matrixtsl.com/wikiv7/index. ... ming_Tools

I'll see if we can investigate why mLoader is having issues.