[KeithInAsia]

It says that the csv file that you generate manually should be placed in the build directory.   Where is that?    The build directory gets destroyed when you do a clean… so — what location are they talking about?

And why wouldn’t the support people here just explain that me?   I have never seen the instructions on this — and the support people (person) would not direct me to those instructions… they can’t be that difficult to follow.

I just don’t know what they are considering the build directory.

With one more sentence — my problem is correctly solved… and to think they wanted to charge me for this.

K.

[KeithInAsia]

NOTICE:    The previous explanation will work until you rebuild the project.   VisualGDB will rebuild with the original default partition table file.

 

I asked the VisualGDB people to supply the correct answer — but they refused until I paid money for it.    I already pay for 2 licenses.   At some point, they are going to do the right thing and bring their tool up to speed.

[KeithInAsia]

The people as VisualGBD did not feel that this area was important enough to take a few minutes to describe the solution.  It took me a lot longer — but here is the solution:

SOLUTION:
This is for Windows Developers. Other platforms will be similar.

TOOLS: I assume you have all this on your system. Only Git Bash may be missing in some standard build environments. (I use Github and have installed the standard tools.)

VS2019
VisualGDB
Git Bash
Python V3

General Steps to Change the Partition Table:

1) Edit your source csv file to include all your correct partition information
2) Generate a binary file by using the gen_esp32part.py python tool.
3) Place the final “partition-table.bin” in the correct build location.

Specific Instructions:

1) Create a working directory somewhere in your project source area. Avoid building in your root directory area as these files may be destroyed during various operations.

2) I strongly suggest cloning all the Github based example files from:

https://github.com/espressif/esp-idf/tree/master/examples

Inside you will find all the partition tools and sample partition table cvs files.

3) Search for gen_esp32part.py That should be located in examples/esp-idf/components/partition_table directory.

4) Copy that command and sample csv files which are located there to your working directory as needed.

5) Make a working csv file and name it appropriately descriptive. eg. PartitionSingleApp2M.csv

6) Right mouse click in that directory and select ‘Git Bash here’ That will open Git Bash and have it pointing already into that directory.

7) Invoke your Python tool which converts the csv working file to the final partition table bin

Here is a sample of the instruction:
python gen_esp32part.py PartitionSingleApp2M.csv partition-table.bin

(There are many various options in that tool not talked about here)

8) The final file name appears to be dependant on the VisualGDB build system (I could be wrong on this). Move your newly generated partition-table.bin file into and replace the existing one at:

<project dirctory> /build/VisualGDB/Debug/partition-table/ <file is here>

WARNING: I strong suspect that the build directories has been in flux and that the fine people at VisualGDB may be monkeying around with the build directory structure. You may need to search for partition-table.bin in the future.

NOTE: VisualGDB doesn’t appear to have any reliance to the Partition Table settings inside the ESP-IDF Project properties at this time (this is the place where you edit the sdkconfig file). The better solution for the future would be for you to have chosen your new csv file there and the build system would convert it for you and place the final binary in the correct location automatically.

NOTE: The startup software in your core build is pretty good about finding errors in the partition table. You will notice a confirmation of your table settings in the normal serial port debug print statements. If you have errors, they will show error message in red following that table print out.

That should do it.

[KeithInAsia]

SOLUTION:
This is for Windows Developers. Other platforms will be similar.

TOOLS: I assume you have all this on your system. Only Git Bash may be missing in some standard build environments. (I use Github and have installed the standard tools.)

VS2019
VisualGDB
Git Bash
Python V3

General Steps to Change the Partition Table:

1) Edit your source csv file to include all your correct partition information
2) Generate a binary file by using the gen_esp32part.py python tool.
3) Place the final “partition-table.bin” in the correct build location.

Specific Instructions:

1) Create a working directory somewhere in your project source area. Avoid building in your root directory area as these files may be destroyed during various operations.

2) I strongly suggest cloning all the Github based example files from:

https://github.com/espressif/esp-idf/tree/master/examples

Inside you will find all the partition tools and sample partition table cvs files.

3) Search for gen_esp32part.py That should be located in examples/esp-idf/components/partition_table directory.

4) Copy that command and sample csv files which are located there to your working directory as needed.

5) Make a working csv file and name it appropriately descriptive. eg. PartitionSingleApp2M.csv

6) Right mouse click in that directory and select ‘Git Bash here’ That will open Git Bash and have it pointing already into that directory.

7) Invoke your Python tool which converts the csv working file to the final partition table bin

Here is a sample of the instruction:
python gen_esp32part.py PartitionSingleApp2M.csv partition-table.bin

(There are many various options in that tool not talked about here)

8) The final file name appears to be dependant on the VisualGDB build system (I could be wrong on this). Move your newly generated partition-table.bin file into and replace the existing one at:

<project dirctory> /build/VisualGDB/Debug/partition-table/ <file is here>

WARNING: I strong suspect that the build directories has been in flux and that the fine people at VisualGDB may be monkeying around with the build directory structure. You may need to search for partition-table.bin in the future.

NOTE: VisualGDB doesn’t appear to have any reliance to the Partition Table settings inside the ESP-IDF Project properties at this time (this is the place where you edit the sdkconfig file). The better solution for the future would be for you to have chosen your new csv file there and the build system would convert it for you and place the final binary in the correct location automatically.

NOTE: The startup software in your core build is pretty good about finding errors in the partition table. You will notice a confirmation of your table settings in the normal serial port debug print statements. If you have errors, they will show error message in red following that table print out.

That should do it.

[KeithInAsia]

m.ridoni,

You wrote “I’ve set up a custom partition table for my project. VisualGDB correctly handles the CSV file, generates the correct .bin partition table and is able to flash it along with the rest of the application.”

Can you point me to the location of where this is documented?     I don’t see where VisualGDB correctly handles the CSV file.  I don’t know what commend in VGDB generates the correct .bin portion table — nor do I have the understanding on how it is able to flash that along with the rest of the application.

I’m happy to read those instructions if you can point me to them.   Thanks.

 

I see you have allocated about 1.3M in your partitions…   My app is now over 1M as well…   I think developers who are successful with the VGDB tool will certainly easily exceed 1M with BT and Wifi enabled.

[KeithInAsia]

R2COM — These guys must be hurting really badly for money.   I’m current with 2 licenses — and they won’t support me because my app has exceeded 1M in size.  (they consider this a rare and unique and unexpected occurrence which is not covered by a license fee).

[KeithInAsia]

OK.. so your tool pretty much runs out of gas once project size exceeds a build 1M in size.   Ok.  If that is the limit you propose.

I will find my own answer without your help.

 

So we pay our licenses fees for you to fix your bugs?    That is somewhat a strange statement…   I don’t get paid for bug fixes.

 

These partition table issues have been raised before in your forums about 1/2 dozen times already.  BUT you failed to really answer those questions thoroughly with a full explanation before now…  or I would have not asked to raise the issue again.

If I have outgrown your tools — I won’t be renewing this year.   I’ll let you know later.

Thank you…

 

 

 

[KeithInAsia]

I have looked through all your forum posts here on custom partition tables for apps that exceed 1M — and require custom flash tables.     There aren’t full instructions on this — there are bits and pieces and a fair amount of uncertainty on the exact steps.

You should already pretty much know this process since your primary expertise is the build tools.

I’m heavy in circuit design, board layout tools, and C++ — so I have a lot of my plate.        If you can’t afford to spend a few minutes on putting the instructions in a list — I’ll figure out something without you…

I think this is certainly a strike against you.   I think this is exactly part of what you need to be handling — especially for customers who are deep into the tools and making larger apps.

[KeithInAsia]

This thread and post looks normal now… I suspect your forum software system has got some glitches…

 

[KeithInAsia]

I’m not asking for project-specific help… this is build process help.    This is general tool stuff

I thought for a moment that the system did not get my last post — but I see you moved it into a previous category — I almost reposted it again thinking that we had a software glitch and the post was not received….

Now I see that you’re moving my posts around to hide them — presumably to hide them?

[KeithInAsia]

The build process is working nicely…. I see that you have fixed the bug that prevented the project from immediately reloading when deleting a source file.    Things look more stable.  Thanks.

[KeithInAsia]

I was correct the first time… the idf source files are in directories at the top of the build tree view.   Shouldn’t our fundamental files be all included there?

[KeithInAsia]

I was mistaken above — the area that I’m talking about is a place where you locate CMake files… it kind of looks like the directory structure of a build — so it looked like build space.

[KeithInAsia]

Comments…

Your fix is working but it is not including the BT directories in the normal components build space.   This is the place where your test projects normally place idf code for project builds.

How do we keep things more standard and normalized in the standard project build space?   If we don’t pursue the correct wholesome solution — we’ll end up having problems down the line.

 

 

[KeithInAsia]

“Using header discovery to reference missing ESP-IDF functionality”???

What are you talking about?     When you expand out a project and need to use more of the IDF, you logically add your code and then reference IDF header file which imports those elements that you want to use.

This is kind of how it has been done for the past 30+ years?    Can you be more specific on what you mean by “own system of components and configuration entries”?    What specific action is the correct action for adding more functionality from including other .c and .h files?

 

Your recommended link https://docs.espressif.com/projects/esp-idf/en/latest/esp32/ is just a general starting point.  I have been all through that documentation many times.  It carefully articulates the use of the Eclipse IDE (mostly) and doesn’t recommend your tools (that I am aware of).     If I only followed their one-way approach — I would not be your customer today.

If you have a more specific point to make — happy to hear it.

 

 

 

 

 

 

 

[Author]

Posts