Flowcode Support Board

Posted: **Tue May 13, 2025 6:57 pm**

Dear Support Team,

I’m attempting to migrate my project from the PIC16F18345 to the PIC16F18444 using Flowcode 10, but the resulting binary does not behave as expected on the new target. Several key functions that worked correctly on the legacy PIC now show abnormal behavior:

Issues Observed on PIC16F18444:

EEPROM Write Failure:

The EEPROM.Write() function is not working correctly.
When writing 0x01, the value stored in EEPROM is consistently 0x00.

EEPROM Read Uncertainty:

I suspect EEPROM.Read() is functioning, but I cannot confirm this because I’m unable to successfully store a value and then retrieve it.

Analog Input Malfunction:

I connected a potentiometer to an analog pin and verified voltage changes from 0V to 5V.
However, the ADC.GetByte() function always returns the same value — it does not reflect the voltage variation as expected (should vary from 0 to 255).

UART Debug Output Corrupted:

When attempting to send debug messages via UART (RS232), the output is unreadable.
I observe many '?' characters and frame errors, suggesting baud rate or signal configuration issues.

Given the number of unrelated subsystems affected (EEPROM, ADC, UART), it seems likely that the PIC16F18444 support in Flowcode 10 may be incomplete or improperly configured.

Could you please investigate and confirm whether full support for the PIC16F18444 is in place, or if updates are required?

Thank you for your support.

Best regards,

Fernando

Posted: **Tue May 13, 2025 10:59 pm**

Dear Support Team,

To assist with troubleshooting, I’ve attached a minimal test program designed to:

Read an analog value using ADC.GetByte() from a potentiometer connected to an analog input.
Send the result over the UART (RS232) for debugging purposes.

This test confirms that basic peripheral functions (ADC and UART) are not working properly on the PIC16F18444 within Flowcode 10. Combined with the EEPROM issues previously reported, this raises further concerns about the completeness of device support.

Please review the PIC16F18444 implementation in Flowcode 10 and advise on any updates or workarounds.

Best regards,

Fernando

Posted: **Wed May 14, 2025 10:05 am**

Hello.
For the EEPROM, Within the configuration settings, have you tried by setting SAF Enabled bit to SAF Enabled?
For the ADC you have the same results no matter what ADC pin you have tried?
To eliminate compiler bugs, what about trying with a different compiler version, lower than XCX8 v3.0, e.g v2.50?
Instructions can be found on the Wiki here
I would recommend the top version of keeping the original compiler.

As low voltage programming is enabled, one of the port b pins are reserved for that so will be unavailable to use.

Posted: **Wed May 14, 2025 11:42 am**

Hello.
I have replicated the ADC issue within a simulator and have spotted issues within the ADC CAL for this Microcontroller.
The only problem is I don't have the microcontroller, so I might need you help testing the ADC for me, when I have made the changes.
The issue could even be the fcdx calling the wrong ADC version.
Leave it with me, I will see if I can fix it.

Posted: **Wed May 14, 2025 12:04 pm**

Hello I believe I have now got the ADC to work.
If you browse to this location using File Explorer, it's hidden by default so just paste the link into your address bar.

Code: Select all

%ProgramData%\MatrixTSL\FlowcodeV10\FCD\PIC\

Replace the original file with the attached version.
If Flowcode is already open, then you will need to reload your project.
If you run any component updates, then the fcdx you added will be overwritten.

Posted: **Wed May 14, 2025 1:13 pm**

medelec35 wrote: ↑
Wed May 14, 2025 10:05 am
Hello.
For the EEPROM, Within the configuration settings, have you tried by setting SAF Enabled bit to SAF Enabled?
For the ADC you have the same results no matter what ADC pin you have tried?
To eliminate compiler bugs, what about trying with a different compiler version, lower than XCX8 v3.0, e.g v2.50?
Instructions can be found on the Wiki here
I would recommend the top version of keeping the original compiler.

As low voltage programming is enabled, one of the port b pins are reserved for that so will be unavailable to use.

Dear Martin,

Thank you very much for your suggestions and support.

I originally developed the code using Flowcode 8, and it had been running reliably on the PIC16F18345 since 2019. The issues only began during the COVID-19 pandemic, when lead times for the PIC16F18345 extended to over 52 weeks, making procurement extremely difficult.

Toward the end of 2024, our company acquired the PIC16F18444 as a functional replacement for the PIC16F18345. However, I encountered compilation issues with Flowcode 8, which prompted me to purchase the Flowcode 10 upgrade. Unfortunately, even with Flowcode 10, the code failed to compile for the PIC16F18444 until Matrix provided a library update.

With the update, I was finally able to compile the code, but testing revealed that the PCBA using the PIC16F18444 was not functioning correctly.

EEPROM Issue:
The first problem I noticed was that EEPROM.Write() was not working. I verified this by reading the EEPROM with a PICkit — values were not being stored (always 0x00).

Low Battery LED Always On:
During testing, we also observed that the low battery LED remained constantly on, regardless of whether the battery sensor input was at 5V or GND.

UART Debugging Failed:
I attempted to use the UART for debug messages, but the output was unreadable, likely due to configuration or peripheral issues.

ADC Not Responding:
I then tried reading analog values using a potentiometer, but ADC.GetByte() does not respond to voltage changes.

Direct C Code Attempts:
I even attempted to bypass Flowcode libraries by writing raw C code based on the PIC16F18444 datasheet to directly configure and operate peripherals, suspecting library issues. However, the behavior remained inconsistent.

Emulator Limitations:
I tried running tests in the Flowcode 10 emulator, but the EEPROM console didn't show initial values and register behavior seemed inconsistent — possibly due to incorrect register mappings.

As a result, I’m currently stuck:

Returning to the PIC16F18345 is not viable due to supply constraints.
Migrating to the PIC16F18444 has not succeeded due to what appear to be incomplete or incorrect Flowcode 10 support for this device.

Apologies for the lengthy explanation, but I hope this helps contextualize the situation.

Regarding your suggestions:

Low Voltage Programming: This is disabled.
Flowcode Version: I’ve tried both version 8 and 10, without success.
ADC Pins: Our PCBA uses 9 ADC sensors. Since both EEPROM and UART are non-functional for debugging, I will explore further tests to confirm ADC functionality.

Thank you once again for your time and assistance.

Best regards,

Fernando

Posted: **Wed May 14, 2025 1:33 pm**

Hello.
While I'm typing this, the 16F18444.fcdx file I attached is showing as not downloaded as of yet, so it looks like you have not tested ADC with the modified file.

Can you follow the instructions on this post.

No need to change the compiler version as there was an issue with ADC.
I'm going to look into EEPROM as well
If I need to make any changes I will let you know.

Posted: **Wed May 14, 2025 1:59 pm**

medelec35 wrote: ↑
Wed May 14, 2025 12:04 pm
Hello I believe I have now got the ADC to work.
If you browse to this location using File Explorer, it's hidden by default so just paste the link into your address bar.
Code: Select all
%ProgramData%\MatrixTSL\FlowcodeV10\FCD\PIC\
Replace the original file with the attached version.
If Flowcode is already open, then you will need to reload your project.
If you run any component updates, then the fcdx you added will be overwritten.

Dear Martin,

I found the file in folder "C:\Program Files (x86)\Flowcode v10\DefaultData\FlowcodeV10\FCD\PIC".
I will test, thank you.

Best regards,

Fernando

Posted: **Wed May 14, 2025 2:33 pm**

medelec35 wrote: ↑
Wed May 14, 2025 10:05 am
Hello.
For the EEPROM, Within the configuration settings, have you tried by setting SAF Enabled bit to SAF Enabled?
For the ADC you have the same results no matter what ADC pin you have tried?
To eliminate compiler bugs, what about trying with a different compiler version, lower than XCX8 v3.0, e.g v2.50?
Instructions can be found on the Wiki here
I would recommend the top version of keeping the original compiler.

As low voltage programming is enabled, one of the port b pins are reserved for that so will be unavailable to use.

Dear Martin,

Regarding to your comment about SAF, I don't want to save non-volatile data on Flash.

While reviewing the XML file you sent (16F18444.fcdx), I noticed that the UART interrupt issue on the PIC16F18444 — including both UART and TIMER — was caused by an incorrect register address:

Old 16F18444.fcdx[:

Code: Select all

<!-- CRC: 90CF26913586BBA787FE92D553771933B2BECC5EA2D3003609AE2EE90C7D3CBADA6183FD7E79AA9B6577EF8789F001E82199345CB81F199F08EB499B5700206FABB24D739BCDFCC30C3CAEE8E7DA6987B678648A35DED1DC394CD0A8E7E870F3C12376B2536502A10294774877944992C19BD19A7F72FE12A2C59BAF674D3D127DBB39C6A70F77ACD8B937FECF905438E3F5FA80E7010969233FBE92E49B97AEDB3084B52383ABAA086944AE325796A6E12CF4674B1156F72604535FBCEB74C043A1300EB085C421EC447A7A7C3AA69E9E27863BF8B478B1 -->
<!-- REVISION: 3.0 -->
<!-- GUID: 6FD9FD89-EF7E-4004-BE11-99FA58D170EC -->
<!-- DATE: 06\05\2025 -->
    :::::
    <adc type='33' bits='12' >
    :::::
    <interrupt ident='RXINT0' type='comms' name='UART RXINT0' handler='#ifndef MX_INTHANDLER_PIR1_RCIF\n#define MX_INTHANDLER_PIR1_RCIF\nif (ts_bit(PIR1, RCIF) &amp;&amp; ts_bit(PIE1, RCIE))\n{\n\tFCM_%n();\n\tcr_bit(PIR1, RCIF);\n}\n#else\n#warning &quot;This interrupt has previously been enabled, so the macro &lt;%n&gt; may never get called.&quot;\n#endif\n' enable='st_bit(PIE1, RCIE);\nst_bit(INTCON, PEIE);\n' disable='cr_bit(PIE1, RCIE);\n' />
    <interrupt ident='TXINT0' type='comms' name='UART TXINT0' handler='#ifndef MX_INTHANDLER_PIR1_TXIF\n#define MX_INTHANDLER_PIR1_TXIF\nif (ts_bit(PIR1, TXIF) &amp;&amp; ts_bit(PIE1, TXIE))\n{\n\tFCM_%n();\n\tcr_bit(PIR1, TXIF);\n}\n#else\n#warning &quot;This interrupt has previously been enabled, so the macro &lt;%n&gt; may never get called.&quot;\n#endif\n' enable='st_bit(PIE1, TXIE);\nst_bit(INTCON, PEIE);\n' disable='cr_bit(PIE1, TXIE);\n' />
    :::::

New 16F18444.fcdx:

Code: Select all

<!-- CRC: 90CF26913586BBA787FE92D553771933B2BECC5EA2D3003609AE2EE90C7D3CBADA6183FD7E79AA9B6577EF8789F001E82C88DA37D76DFD220CBD1DF30DF2EE3DEBF4E1791E51DEDDA4D1C56CD1580BF57D5B6ABC34200F1F394CD0A8E7E870F3C12376B2536502A10294774877944992C19BD19A7F72FE12A2C59BAF674D3D127DBB39C6A70F77ACD8B937FECF905438E3F5FA80E7010969233FBE92E49B97AEDB3084B52383ABAA086944AE325796A6000F09FD1979F557AC67361F26AE627C6C4D64725B33C47707369D99911C23D5D43797C197BFDEC5 -->
<!-- REVISION: 2.0 -->
<!-- GUID: 6FD9FD89-EF7E-4004-BE11-99FA58D170EC -->
<!-- DATE: 07\11\2022 -->
    :::::
    <adc type='36' bits='12' >
    :::::
    <interrupt ident='RXINT0' type='comms' name='UART RXINT0' handler='#ifndef MX_INTHANDLER_PIR3_RC1IF\n#define MX_INTHANDLER_PIR3_RC1IF\nif (ts_bit(PIR3, RC1IF) &amp;&amp; ts_bit(PIE3, RC1IE))\n{\n\tFCM_%n();\n\tcr_bit(PIR3, RC1IF);\n}\n#else\n#warning &quot;This interrupt has previously been enabled, so the macro &lt;%n&gt; may never get called.&quot;\n#endif\n' enable='st_bit(PIE3, RC1IE);\nst_bit(INTCON, PEIE);\n' disable='cr_bit(PIE3, RC1IE);\n' />
    <interrupt ident='TXINT0' type='comms' name='UART TXINT0' handler='#ifndef MX_INTHANDLER_PIR3_TX1IF\n#define MX_INTHANDLER_PIR3_TX1IF\nif (ts_bit(PIR3, TX1IF) &amp;&amp; ts_bit(PIE3, TX1IE))\n{\n\tFCM_%n();\n\tcr_bit(PIR3, TX1IF);\n}\n#else\n#warning &quot;This interrupt has previously been enabled, so the macro &lt;%n&gt; may never get called.&quot;\n#endif\n' enable='st_bit(PIE3, TX1IE);\nst_bit(INTCON, PEIE);\n' disable='cr_bit(PIE3, TX1IE);\n' />
    :::::

Given this, I would like to ask if the issues I’m experiencing with INTERNAL EEPROM and UART (RX/TX) components' functionality could also be related to similar register address mismatches.

Would it be possible for you to verify whether the register mappings for INTERNAL EEPROM and UART are correct in the current Flowcode 10 configuration for the PIC16F18444?

Thank you once again for your support.

Best regards,

Fernando

Posted: **Wed May 14, 2025 2:48 pm**

CamargoF wrote: ↑
Wed May 14, 2025 1:59 pm
medelec35 wrote: ↑
Wed May 14, 2025 12:04 pm
Hello I believe I have now got the ADC to work.
If you browse to this location using File Explorer, it's hidden by default so just paste the link into your address bar.
Code: Select all
%ProgramData%\MatrixTSL\FlowcodeV10\FCD\PIC\
Replace the original file with the attached version.
If Flowcode is already open, then you will need to reload your project.
If you run any component updates, then the fcdx you added will be overwritten.
Dear Martin,

I found the file in folder "C:\Program Files (x86)\Flowcode v10\DefaultData\FlowcodeV10\FCD\PIC".
I will test, thank you.

Best regards,

Fernando

Did not work.
I search all my disk and I found the folder you mention (C:\ProgramData\MatrixTSL\FlowcodeV10\FCD\PIC) and I will try again.

Sorry

Flowcode Support Board

Multiple Functional Issues with PIC16F18444 in Flowcode 10

Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10

Re: Multiple Functional Issues with PIC16F18444 in Flowcode 10