Hello,

We are pleased to hear that it is working well after Rudolphs advice,

Yes, please note that the register values for the tag and the coordinates will be updated to reflect the current touch status even after the interrupt has triggered and so it is important to read the values as soon as possible after the interrupt. If there is a delay, the touch conditions may have changed (for example the user may have moved their finger or lifted it off the screen) and so you may see newer values compared to those which triggered the interrupt.

Best Regards, BRT Community

Hello,

For some general background information, the bootloader presents an interface for both programming the FT900 and for the GDB bridge to query the hardware during debugging. In simplified terms, some of the functionality for debugging is on the GDB bridge debugger and the rest is in the bootloader. The bootloader is 4kB but it is not in a protected area unless the linker script is modified (the v2.6.0 default linker script protects the bootloader).

Here are some possible reasons that could be causing the debugger issue.

• There is an issue with the bootloader (this doesn’t appear to be the issue here).
  • The first part of the sequence is to program the Flash. This succeeds since this is a hardware function as the one-wire interface has direct access to the Flash interface and can program the device without any trouble under most circumstances. The hardware will respond correctly to requests such as hardware register reads as well.
  • There is code in the bootloader which then performs additional work when the one-wire connects from the debugger bridge. This code is responsible for responding to a set of commands required by the GDB bridge program. The GDB bridge will ALSO verify the connection by performing some hardware register reads as well so it will make some ‘progress’ when compared to when there is no actual device connected.
  • So, if the bootloader is corrupted then the programmer works and the GDB bridge starts but ultimately times out waiting for a response from the bootloader code on the FT900. The GDB bridge console can be shown by Eclipse by changing a setting.
  • A remedy for this is to reprogram the bootloader with the FT9xx Programmer Utility. Then ensure that it is not being overwritten by the code by checking the size of the code programmed. The ft32-elf-size command run at the end of the build will tell you the size. It is a raw code size so it is possible that there are rarely used linker commands (or linker script options) which can move code around. If the code is small enough then it should run properly after restoring the bootloader.
• There is an issue with Java or Python installation; permissions to create or access to sockets on the debugging machine; or virus scanners analysing program behaviour.
  • Any of the above could be breaking this. The fact that it works from the command line makes me think it could be one of these reasons. So, Eclipse spawns a process to run the GDB Bridge code which is in Python. Then when debugging starts, Eclipse remote debugging will connect to the GDB Bridge code through sockets.
  • The permissions, or memory available to, or the behaviour of spawned processes from the Java runtime (which runs Eclipse) may not allow the connection.
  • The process that runs Python (see above) might not be allowed to connect or be sandboxed by the virus scanner.
  • The GDB_bridge python code not being able to create a socket for Eclipse to connect.
  • Eclipse may not be allowed to connect to the sockets.
  • You can test the connection to the sockets on the command line with ‘ft32-elf-gdb <file>.elf’ command line. Then “target remote localhost:9998”.
• A program can start running on the FT900 and disable interrupts and do something that locks out the debugger. It shouldn’t but sometimes pressing the reset button and connecting to the debugger works, whereas leaving it a few seconds after resetting doesn’t work.
• Check the debugger cable is seated correctly.

Best regards, BRT Community

Hello Darren,

Thank you for the update, I appreciate this may be an issue where it is tricky to definitively narrow down a set of steps for reproduction.

I have tried to reproduce this behaviour, but haven't had any luck as of yet. Just out of curiosity can you reproduce this error on multiple machines?
In any case i will make a bug report to the developers on this issue.

Best Regards,
BRT Community

Hi Darren, Kaetemi,

Our developers are currently working on a fix for this and we will let you know when it is available,

Best Regards, BRT Community

Hello,

Thank you for your post, unfortunately there isn't any setting available which would allow you to alter the Audio Buffer settings in ESD.
I suspect this issue is related to the emulator in ESD for utilizing audio playback via the PC, do you have any advice on reproduction of this issue?
For example should i open a project and then wait 10 minutes? or will a simple lock and unlock of the PC recreate this behavior?

Best Regards,
BRT Community

Hi Jonathan,

The INT pin should follow the state of the interrupt from the capacitive touch panel when the BT81x is in sleep mode. If you scope the INT output from EVE and put EVE into the sleep mode, you should see low pulses each time you touch the screen.

In active mode, you can check the REG_INT_FLAGS to see which source caused the interrupt. Note that reading it will clear the flags and so when you see INT low the first read will give the flags.

The Interrupt operates similarly to most MCUs whereby you have the global INT bit (REG_INT_EN) to enable interrupts and then you have mask bits to determine which sources will generate an interrupt (REG_INT_MASK). Once the INT pin is asserted, your MCU should read REG_INT_FLAGS to see which source caused it. We have a table of interrupt sources in the BT815/6 datasheet in the Interrupts Section which you can use to see which bits correspond to which source

Some interrupts will occur periodically in normal operation (such as swap) whereas others will only be activated by a user action (such as TAG when the user touches the screen and the tag changes). However, you can set the mask bits such that only the sources you require will generate an interrupt. You may use the TAG or TOUCH interrupt for the application you mentioned where the interrupt occurs on a user touch.

Best Regards, BRT Community

Hello,

Thank you for your questions:

1) resizing the logic nodes is currently not a feature in ESD, you can however view all of the node associated properties if you selected it and view the properties tab in the bottom right on the ESD window. I will suggest this as a feature to the development team.

2) Could you clarify if you wish to store these images on a connected flash IC/card on your MCU? or is it sufficient to store these in the program memory? The EVE_LoadFile_FATFS.c and EVE_LoadFile_STDIO.c files may be useful in the former case if you require to load data from flash connected to your MCU. See the EVE_Util_loadRawFile function in the latter.

3) By default yes the touch calibration routine will be run on every power cycle, however if you wish you can run the routine once, store the values captured and use these to update the REG_TOUCH_TRANSFORM_A-F accordingly during intilization.

Best Regards,
BRT Community

Hello,

Hello,
of course, you can zip project and forward via sharing service, thank you a lot for your support here:)  This is not compatible with ESD it means that if I will develop some screens via EVE screen designer it will be not possible to used it?

Thank you I will send you an email with a download link.

Yes that is correct the ESD framework and the lower level framework are not compatible with each other, if you were to utilise the lower level framework you would need to manually program displays and display logic, however you can use the EVE Screen Editor tool to help with this process.

Best Regards,
BRT Community