Another thing i noticed is that you place all elements in one row,i use multiple rows in mycode, you think that large amount of elemen lines can cause problems too?
UPDATE]: i try to use much lesser lines of elements in each table (i had ~40 elements/line, now i have 1000/line), and it seems that problem is fixed (at least for now). So there might be indeed a problem managing large number of element rows or better not use rows but have all elements in one row (even if there are 15000 of them)?...
Ok, finally problem resolved by using the new RC20 cow basic compiler 98.07
As Evan explained, the issue was in the chip description file. There are also changes for the Q10series in the new libraries.
I have looked into the Q10 core issues in July 2020. The change log shows two changes 1) Correction of the .DAT to ensure the Sector RAM was excluded from normal RAM operations 2) A correction in the compiler to ensure TBLPTRU was appropriately managed on Q10 chips with less than 32768 bytes of PROGMEM.
Neither of these would impact a Q43 as the Q43 does have Sector RAM and the Q43 has more than 32767 bytes of PROGMEM (so, the TBLPTRU is being managed appropriately in the Q43 as we can see from the ASM/S files).
The fix back in 2020 for the Q10 issue. Get you to use RC20 which had these fixes. Which would have resolved the issue.
Back the Q43 issue.
Your provided .S compiled here also. I can see no obvious issues.
So, we have to look elsewhere.
I have taken the test program that I wrote in July 2020 ( the same post ) and I have increased the size of the tables to fill the PROGMEM of the 27Q43 ( baby of the 47Q43 you have ), I have added the millis() interrupt and now it shows the tables and the processing time. This test is important as this not only shows that the PROGMEM read is ok, it shows this interrupt and millis() handler is working. millis() is far more complex than usart reads.
This test shows 15 tables of 4010 word elements being displayed at 256000 BPS with millis() running. The test completes.
I have rechecked the moment usage again. All looks ok.
The memory and alias usage is compliant with the 0x500–0x24FF range, with only two aliases (AFSR0, AFSR0_H) below the lower bound of 0x500 which is correct as these are FSR0L and FSR0H respectively. No memory addresses exceed the upper limit.
I think we have to rule of the ring buffer and the use of HSerReceive().
Currently, you have extensive use of the function HSERRECEIVEFROM(2). This function set the Comport variable then calls sub HSERRECEIVE then sets the return value in HSERRECEIVEFROM. So, this is not optimised. Set Comport one, Comport = 2 then use the sub HSERRECEIVE( the_variable_you_want_to_set ). This will be a lot faster.
OR
The other idea is to remove the HSERRECEIVEFROM and replace with U2RXB. So, you have the_variable_you_want_to_set = U2RXB If this works with no issues then this would point to an issue in Sub HSerReceive() that is based on the MPLAB-X and we may have to revisited the detailed code in Sub HSerReceive() specificially the error handler.
OR
You can try this in your program. This will be in preference to the library sub. You should still set Comport = 2.
Sub HSerReceive(Out SerData)
Wait Until USART2HasData
// U2RXEN = 1 .... renoved.
if ( U2FERIF = 1 ) then
'UART2 error - clear the error
ON_U2CON1 = 0
ON_U2CON1 = 1
end if
SerData = U2RXB
End Sub
Evan
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Documentation for the use of the AWK program generator.
AWK Script for Generating Test Table Program
Overview
This AWK script generates a test program for programming a target chip and sending large data tables to a terminal. The script creates a program with multiple tables, each containing a specified number of word elements, and outputs them at a baud rate of 256000 BPS while tracking execution time using the millis() function. The generated program is written in a format compatible with the Great Cow BASIC (GCBASIC) compiler.
The test program demonstrates the ability to handle a configurable number of tables (default: 15), each with a configurable number of word elements (default: 4010), and completes successfully. The table size and number of tables can be adjusted via command-line arguments to fit within the program memory (PROGMEM) of the target chip.
Prerequisites
GAWK: The GNU AWK interpreter is required to run the script.
Empty Input File (t.txt): An empty text file is needed as a placeholder for GAWK to process the script. This is not important and just needs to exist.
GCBASIC Compiler: The output file (test.gcb) must be compiled using the GCBASIC compiler to program the target chip.
Usage
To generate the test program, run the following command at a DOS prompt:
-f tabletest.awk: Specifies the AWK script file to execute.
-v ELEMENTS=4010: Sets the number of elements per table (this example: 4010). Adjust this value to fit within the PROGMEM.
-v TABLES=15: Sets the number of tables to generate (this example: 15). Adjust this value to fit within the PROGMEM.
t.txt: An empty text file required for GAWK to process the script.
> test.gcb: Redirects the script output to a file named test.gcb, which is the test program in GCBASIC format.
Script Functionality
The AWK script performs the following tasks:
Chip Configuration:
Configures the target chip as 18F47Q43 with explicit variable declarations (#OPTION Explicit) and low-voltage programming disabled (#CONFIG LVP=OFF).
Sets PORTC.6 as the output pin for TX1 (RC6PPS = 0x10) for serial communication on the 18F26K22.
Serial Communication Setup:
Configures the USART with a baud rate of 256000 BPS (#DEFINE USART_BAUD_RATE 256000).
Enables blocking mode for USART transmission (#DEFINE USART_TX_BLOCKING).
Table Generation:
Creates a configurable number of tables (set via TABLES) with a configurable number of word elements per table (set via ELEMENTS).
Table sizes and counts should be adjusted to fit within the PROGMEM of the target chip.
Each table is named START_CODE followed by the table number (e.g., START_CODE1, START_CODE2, etc.).
Tables are defined as byte arrays containing sequential values from 1 to ELEMENTS.
Data Output:
For each table, the script generates code to:
Read the table length and display it via serial output (HSerPrint data_length).
Output the current time in milliseconds (HSerPrint millis()).
Iterate through each table element, printing it as a left-padded string of 4 characters (HSerPrint leftpad(str(data_buf),4)), followed by a comma (HSerSend 0x2c).
Insert a carriage return and line feed every 50 elements (if data_position % 50 = 0 then HSerPrintCRLF).
Print a newline after each table.
Program Termination:
Outputs "End of Test" to the terminal.
Enters an infinite loop (do...loop) to keep the program running.
Table Definitions:
Defines each table as a byte array with sequential values from 1 to ELEMENTS.
Each table is enclosed in TABLE and END TABLE directives for GCBASIC.
Example Output
For the default settings (ELEMENTS=4010, TABLES=15), the generated program will:
- Create 15 tables named START_CODE1 to START_CODE15.
- Each table contains 4010 word elements (values 1 to 4010).
- Output each table's length, the current millis() value, and the table's elements to the terminal at 256000 BPS.
- Format the output with commas between elements and newlines every 50 elements.
- Conclude with "End of Test" and enter an infinite loop.
PROGMEM Considerations
The 18F26K22 has 64 KB of PROGMEM. The number of tables (TABLES) and elements per table (ELEMENTS) must be chosen to ensure the generated tables fit within this memory.
Each element in a table is a byte, so the total memory used by tables is approximately TABLES * ELEMENTS bytes, plus overhead for program code and table definitions.
To adjust table sizes, modify the ELEMENTS and TABLES parameters in the command-line invocation. For example, to reduce memory usage, you could use:
This generates 10 tables with 2000 elements each, using approximately 20,000 bytes of PROGMEM for the table data.
Notes
The empty file t.txt is required for GAWK to process the script, even though it does not contribute to the output.
The generated test.gcb file must be compiled with the GCBASIC compiler to produce a binary suitable for programming the 18F26K22 chip.
Ensure the target hardware is configured to receive serial data at 256000 BPS.
Verify that the total size of the tables and program code does not exceed the 64 KB PROGMEM limit of the 18F26K22.
Limitations
The script assumes the GCBASIC environment is set up correctly on the target system.
The script does not handle errors related to invalid input parameters (e.g., negative ELEMENTS or TABLES, or values that exceed PROGMEM capacity).
Users must manually calculate or estimate PROGMEM usage when setting ELEMENTS and TABLES to avoid memory overflow. However, the compiler and programming utility will prevent using a HEX file that is too large.
ok, i've tried the test.gcb and with a few modifications on usart settings and chip it is executed ok. I've set uart speed at 921600bps and it took ~21seconds to read each table.
I've also tried the alternatives of hserreceivefrom(2):
set comport=2
hserreseive(var)
and also the: var= U2RXB
Unfortunately nothing changed, upon initializing of ch376 usb host module it stuck to the same position (after changing uart speed to 1mbps and send a test sequence of 4 bytes where module should respond with one byte, but instead i never got response, hence the freezing), and also with serial communication with a pc, it still crashes (more accurately amstrad start to reset non stop...) when i try to load a file.
As the same 18F47Q43 gcb source code works perfect for 18F47Q10 (apart from the changes in various declarations for CLC, UART registers etc, of course), for some arcane reason something doesn't work right...
Anyway, i only wanted to migrate code to 18F47Q43 to test the DMA function (mostly for placing a byte received from hw uart port to the receive ring buffer), so no urgent need about that anyway...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
i don't remember details after so many years, but according to the old topic: https://sourceforge.net/p/gcbasic/discussion/596084/thread/5398dd8bc1/?limit=25&page=1
quoting:
I've also found this topic: https://sourceforge.net/p/gcbasic/discussion/596084/thread/3adcb7b402/
But i suppose since USART basic function is ok, it doesn't have to do with it...
Last edit: ikonsgr74 1 day ago
I have looked into the Q10 core issues in July 2020. The change log shows two changes 1) Correction of the .DAT to ensure the Sector RAM was excluded from normal RAM operations 2) A correction in the compiler to ensure TBLPTRU was appropriately managed on Q10 chips with less than 32768 bytes of PROGMEM.
Neither of these would impact a Q43 as the Q43 does have Sector RAM and the Q43 has more than 32767 bytes of PROGMEM (so, the TBLPTRU is being managed appropriately in the Q43 as we can see from the ASM/S files).
The fix back in 2020 for the Q10 issue. Get you to use RC20 which had these fixes. Which would have resolved the issue.
Back the Q43 issue.
Your provided .S compiled here also. I can see no obvious issues.
So, we have to look elsewhere.
I have taken the test program that I wrote in July 2020 ( the same post ) and I have increased the size of the tables to fill the PROGMEM of the 27Q43 ( baby of the 47Q43 you have ), I have added the millis() interrupt and now it shows the tables and the processing time. This test is important as this not only shows that the PROGMEM read is ok, it shows this interrupt and millis() handler is working. millis() is far more complex than usart reads.
This test shows 15 tables of 4010 word elements being displayed at 256000 BPS with millis() running. The test completes.
Please try the attached GCB source on your setup. For me this shows that the interrupt and table reads are all good.
I have rechecked the moment usage again. All looks ok.
The memory and alias usage is compliant with the 0x500–0x24FF range, with only two aliases (AFSR0, AFSR0_H) below the lower bound of 0x500 which is correct as these are FSR0L and FSR0H respectively. No memory addresses exceed the upper limit.
I think we have to rule of the ring buffer and the use of HSerReceive().
Currently, you have extensive use of the function HSERRECEIVEFROM(2). This function set the Comport variable then calls sub HSERRECEIVE then sets the return value in HSERRECEIVEFROM. So, this is not optimised. Set Comport one,
Comport = 2
then use the sub HSERRECEIVE( the_variable_you_want_to_set ). This will be a lot faster.OR
The other idea is to remove the HSERRECEIVEFROM and replace with U2RXB. So, you have
the_variable_you_want_to_set = U2RXB
If this works with no issues then this would point to an issue in Sub HSerReceive() that is based on the MPLAB-X and we may have to revisited the detailed code in Sub HSerReceive() specificially the error handler.OR
You can try this in your program. This will be in preference to the library sub. You should still set Comport = 2.
Evan
Documentation for the use of the AWK program generator.
AWK Script for Generating Test Table Program
Overview
This AWK script generates a test program for programming a target chip and sending large data tables to a terminal. The script creates a program with multiple tables, each containing a specified number of word elements, and outputs them at a baud rate of 256000 BPS while tracking execution time using the
millis()
function. The generated program is written in a format compatible with the Great Cow BASIC (GCBASIC) compiler.The test program demonstrates the ability to handle a configurable number of tables (default: 15), each with a configurable number of word elements (default: 4010), and completes successfully. The table size and number of tables can be adjusted via command-line arguments to fit within the program memory (PROGMEM) of the target chip.
Prerequisites
t.txt
): An empty text file is needed as a placeholder for GAWK to process the script. This is not important and just needs to exist.test.gcb
) must be compiled using the GCBASIC compiler to program the target chip.Usage
To generate the test program, run the following command at a DOS prompt:
-f tabletest.awk
: Specifies the AWK script file to execute.-v ELEMENTS=4010
: Sets the number of elements per table (this example: 4010). Adjust this value to fit within the PROGMEM.-v TABLES=15
: Sets the number of tables to generate (this example: 15). Adjust this value to fit within the PROGMEM.t.txt
: An empty text file required for GAWK to process the script.> test.gcb
: Redirects the script output to a file namedtest.gcb
, which is the test program in GCBASIC format.Script Functionality
The AWK script performs the following tasks:
18F47Q43
with explicit variable declarations (#OPTION Explicit
) and low-voltage programming disabled (#CONFIG LVP=OFF
).Sets PORTC.6 as the output pin for TX1 (
RC6PPS = 0x10
) for serial communication on the 18F26K22.Serial Communication Setup:
#DEFINE USART_BAUD_RATE 256000
).Enables blocking mode for USART transmission (
#DEFINE USART_TX_BLOCKING
).Table Generation:
TABLES
) with a configurable number of word elements per table (set viaELEMENTS
).START_CODE
followed by the table number (e.g.,START_CODE1
,START_CODE2
, etc.).Tables are defined as byte arrays containing sequential values from 1 to
ELEMENTS
.Data Output:
For each table, the script generates code to:
HSerPrint data_length
).HSerPrint millis()
).HSerPrint leftpad(str(data_buf),4)
), followed by a comma (HSerSend 0x2c
).if data_position % 50 = 0 then HSerPrintCRLF
).Program Termination:
Enters an infinite loop (
do...loop
) to keep the program running.Table Definitions:
ELEMENTS
.TABLE
andEND TABLE
directives for GCBASIC.Example Output
For the default settings (
ELEMENTS=4010
,TABLES=15
), the generated program will:- Create 15 tables named
START_CODE1
toSTART_CODE15
.- Each table contains 4010 word elements (values 1 to 4010).
- Output each table's length, the current
millis()
value, and the table's elements to the terminal at 256000 BPS.- Format the output with commas between elements and newlines every 50 elements.
- Conclude with "End of Test" and enter an infinite loop.
PROGMEM Considerations
TABLES
) and elements per table (ELEMENTS
) must be chosen to ensure the generated tables fit within this memory.TABLES * ELEMENTS
bytes, plus overhead for program code and table definitions.ELEMENTS
andTABLES
parameters in the command-line invocation. For example, to reduce memory usage, you could use:This generates 10 tables with 2000 elements each, using approximately 20,000 bytes of PROGMEM for the table data.
Notes
t.txt
is required for GAWK to process the script, even though it does not contribute to the output.test.gcb
file must be compiled with the GCBASIC compiler to produce a binary suitable for programming the 18F26K22 chip.Limitations
ELEMENTS
orTABLES
, or values that exceed PROGMEM capacity).ELEMENTS
andTABLES
to avoid memory overflow. However, the compiler and programming utility will prevent using a HEX file that is too large.Evan... Enjoy
Last edit: Anobium 9 hours ago
ok, i've tried the test.gcb and with a few modifications on usart settings and chip it is executed ok. I've set uart speed at 921600bps and it took ~21seconds to read each table.
I've also tried the alternatives of hserreceivefrom(2):
set comport=2
hserreseive(var)
and also the: var= U2RXB
Unfortunately nothing changed, upon initializing of ch376 usb host module it stuck to the same position (after changing uart speed to 1mbps and send a test sequence of 4 bytes where module should respond with one byte, but instead i never got response, hence the freezing), and also with serial communication with a pc, it still crashes (more accurately amstrad start to reset non stop...) when i try to load a file.
As the same 18F47Q43 gcb source code works perfect for 18F47Q10 (apart from the changes in various declarations for CLC, UART registers etc, of course), for some arcane reason something doesn't work right...
Anyway, i only wanted to migrate code to 18F47Q43 to test the DMA function (mostly for placing a byte received from hw uart port to the receive ring buffer), so no urgent need about that anyway...