waiting for reply.. anyone?
↧
How to Read/Write FLASH and EEPROM of (Infineon Tricore 1782)
↧
XMC4800: Vector table remap/relocation from flash to RAM (bootloader)
To answer my own question ...
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
In startup assembler file (reset handler), an entry has been added to the copy table to make the start-up script copy vector table from flash to new location in RAM.
In same file the relocate-to-RAM method is called just before main() is called. The relocation could possible be performed in SystemCoreSetup(), but this method is called right at the beginning of the reset handler, where the RAM content has not been loaded and therefore the new RAM vector table is not populated. So I decided to add the new method SYSTEM_relocateVectorsToRam().
In startup_XMC4800.s:
In system_XMC4800.c:
Improvements are welcome, like not hard-coding the size of SYSTEM_ramVectors[].
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
Code:
<snip>
Stack (NOLOAD) :
{
__stack_start = .;
. = . + stack_size;
__stack_end = .;
__initial_sp = .;
} > SRAM_combined
/* vector table in RAM (aligned to 1024 byte) */
.ram_vectors (NOLOAD) : {
. = ALIGN(1024);
__ram_vectors_start = .;
* (.ram_vectors);
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_vectors_end = .;
} > SRAM_combined
__ram_vectors_size = __ram_vectors_end - __ram_vectors_start;
/* functions with __attribute__((section(".ram_code"))) */
.ram_code :
{
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_code_start = .;
<snip>Code:
<snip>
__copy_table_start__:
.long __data_load, __data_start, __data_size
.long __ram_code_load, __ram_code_start, __ram_code_size
.long __Vectors, __ram_vectors_start, __ram_vectors_size
__copy_table_end__:
<snip>In startup_XMC4800.s:
Code:
<snip>
/* relocate vectors to RAM */
ldr r0, =SYSTEM_relocateVectorsToRam
blx r0
ldr r0, =main
blx r0
<snip>Code:
<snip>
__attribute__((section(".ram_vectors")))
uint8_t SYSTEM_ramVectors[512]; /** Place holder for vector table in RAM. Will be placed in correct segment by linker,
filled by reset vector and activated by SYSTEM_relocateVectorsToRam() */
/**
* Relocate vectors to RAM.
*
* Must be called after assembler start-up script performed the copy operation from flash.
*/
void
SYSTEM_relocateVectorsToRam(void) {
/* relocate vector table to RAM */
__disable_irq();
SCB->VTOR = (uint32_t) &SYSTEM_ramVectors;
__DSB();
__enable_irq();
}
<snip>↧
↧
SDMMC app upgrade issues (4.0.22 -> 4.3.22
Hi,
The code you mentioned should not be generated for XMC1 family.
It is a bug in the SDMMC_BLOCK APP v.4.0.24.
Use the attached fixed version. To install it:
1. Download and unzip the update site.
2. Use menu Help>Install DAVE APP/Example/Device Libray...
3. Click on Add.. and then in Local button
4. Browse to the folder where you unzip the update site. Select the folder containing the update site. Click Ok
Attachment 3672
5. Select the SDMMC_BLOCK APP. Click Next
Attachment 3673
6. Step through the rest of the dialogs, and after a restart the new version of the SDMMC_BLOCK will be available.
7. You should be able to upgrade your project. Select to upgrade including beta versions
Attachment 3674
Hope this helps until the release of new version of the APP.
Otherwise, are you using the LED/write protection? If not please deselect them. It will also fix the issue.
Regards,
Jesus
The code you mentioned should not be generated for XMC1 family.
It is a bug in the SDMMC_BLOCK APP v.4.0.24.
Use the attached fixed version. To install it:
1. Download and unzip the update site.
2. Use menu Help>Install DAVE APP/Example/Device Libray...
3. Click on Add.. and then in Local button
4. Browse to the folder where you unzip the update site. Select the folder containing the update site. Click Ok
Attachment 3672
5. Select the SDMMC_BLOCK APP. Click Next
Attachment 3673
6. Step through the rest of the dialogs, and after a restart the new version of the SDMMC_BLOCK will be available.
7. You should be able to upgrade your project. Select to upgrade including beta versions
Attachment 3674
Hope this helps until the release of new version of the APP.
Otherwise, are you using the LED/write protection? If not please deselect them. It will also fix the issue.
Regards,
Jesus
↧
AURIX TC27x Lockstep
Perhaps I don't fully understand your question.
In the TC27x, both CPU0 and CPU1 instances of the TriCore can be lockstepped. In this terminology Core0 is the master and there is an additional checker core. These two cores can that can be lockstepped together (i.e. Core0 is always there and you can optionally enable the checker core). The lockstep monitoring function will compare the outputs from the master and checker cores and report that a failure has occurred to the Safety Management Unit (SMU) for appropriate action.
Hope this helps.
In the TC27x, both CPU0 and CPU1 instances of the TriCore can be lockstepped. In this terminology Core0 is the master and there is an additional checker core. These two cores can that can be lockstepped together (i.e. Core0 is always there and you can optionally enable the checker core). The lockstep monitoring function will compare the outputs from the master and checker cores and report that a failure has occurred to the Safety Management Unit (SMU) for appropriate action.
Hope this helps.
↧
How to Read/Write FLASH and EEPROM of (Infineon Tricore 1782)
waiting for reply.. anyone?
↧
↧
XMC4800: Vector table remap/relocation from flash to RAM (bootloader)
To answer my own question ...
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
In startup assembler file (reset handler), an entry has been added to the copy table to make the start-up script copy vector table from flash to new location in RAM.
In same file the relocate-to-RAM method is called just before main() is called. The relocation could possible be performed in SystemCoreSetup(), but this method is called right at the beginning of the reset handler, where the RAM content has not been loaded and therefore the new RAM vector table is not populated. So I decided to add the new method SYSTEM_relocateVectorsToRam().
In startup_XMC4800.s:
In system_XMC4800.c:
Improvements are welcome, like not hard-coding the size of SYSTEM_ramVectors[].
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
Code:
<snip>
Stack (NOLOAD) :
{
__stack_start = .;
. = . + stack_size;
__stack_end = .;
__initial_sp = .;
} > SRAM_combined
/* vector table in RAM (aligned to 1024 byte) */
.ram_vectors (NOLOAD) : {
. = ALIGN(1024);
__ram_vectors_start = .;
* (.ram_vectors);
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_vectors_end = .;
} > SRAM_combined
__ram_vectors_size = __ram_vectors_end - __ram_vectors_start;
/* functions with __attribute__((section(".ram_code"))) */
.ram_code :
{
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_code_start = .;
<snip>Code:
<snip>
__copy_table_start__:
.long __data_load, __data_start, __data_size
.long __ram_code_load, __ram_code_start, __ram_code_size
.long __Vectors, __ram_vectors_start, __ram_vectors_size
__copy_table_end__:
<snip>In startup_XMC4800.s:
Code:
<snip>
/* relocate vectors to RAM */
ldr r0, =SYSTEM_relocateVectorsToRam
blx r0
ldr r0, =main
blx r0
<snip>Code:
<snip>
__attribute__((section(".ram_vectors")))
uint8_t SYSTEM_ramVectors[512]; /** Place holder for vector table in RAM. Will be placed in correct segment by linker,
filled by reset vector and activated by SYSTEM_relocateVectorsToRam() */
/**
* Relocate vectors to RAM.
*
* Must be called after assembler start-up script performed the copy operation from flash.
*/
void
SYSTEM_relocateVectorsToRam(void) {
/* relocate vector table to RAM */
__disable_irq();
SCB->VTOR = (uint32_t) &SYSTEM_ramVectors;
__DSB();
__enable_irq();
}
<snip>↧
SDMMC app upgrade issues (4.0.22 -> 4.3.22
Hi,
The code you mentioned should not be generated for XMC1 family.
It is a bug in the SDMMC_BLOCK APP v.4.0.24.
Use the attached fixed version. To install it:
1. Download and unzip the update site.
2. Use menu Help>Install DAVE APP/Example/Device Libray...
3. Click on Add.. and then in Local button
4. Browse to the folder where you unzip the update site. Select the folder containing the update site. Click Ok
Attachment 3672
5. Select the SDMMC_BLOCK APP. Click Next
Attachment 3673
6. Step through the rest of the dialogs, and after a restart the new version of the SDMMC_BLOCK will be available.
7. You should be able to upgrade your project. Select to upgrade including beta versions
Attachment 3674
Hope this helps until the release of new version of the APP.
Otherwise, are you using the LED/write protection? If not please deselect them. It will also fix the issue.
Regards,
Jesus
The code you mentioned should not be generated for XMC1 family.
It is a bug in the SDMMC_BLOCK APP v.4.0.24.
Use the attached fixed version. To install it:
1. Download and unzip the update site.
2. Use menu Help>Install DAVE APP/Example/Device Libray...
3. Click on Add.. and then in Local button
4. Browse to the folder where you unzip the update site. Select the folder containing the update site. Click Ok
Attachment 3672
5. Select the SDMMC_BLOCK APP. Click Next
Attachment 3673
6. Step through the rest of the dialogs, and after a restart the new version of the SDMMC_BLOCK will be available.
7. You should be able to upgrade your project. Select to upgrade including beta versions
Attachment 3674
Hope this helps until the release of new version of the APP.
Otherwise, are you using the LED/write protection? If not please deselect them. It will also fix the issue.
Regards,
Jesus
↧
How to Read/Write FLASH and EEPROM of (Infineon Tricore 1782)
waiting for reply.. anyone?
↧
XMC4800: Vector table remap/relocation from flash to RAM (bootloader)
To answer my own question ...
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
In startup assembler file (reset handler), an entry has been added to the copy table to make the start-up script copy vector table from flash to new location in RAM.
In same file the relocate-to-RAM method is called just before main() is called. The relocation could possible be performed in SystemCoreSetup(), but this method is called right at the beginning of the reset handler, where the RAM content has not been loaded and therefore the new RAM vector table is not populated. So I decided to add the new method SYSTEM_relocateVectorsToRam().
In startup_XMC4800.s:
In system_XMC4800.c:
Improvements are welcome, like not hard-coding the size of SYSTEM_ramVectors[].
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
Code:
<snip>
Stack (NOLOAD) :
{
__stack_start = .;
. = . + stack_size;
__stack_end = .;
__initial_sp = .;
} > SRAM_combined
/* vector table in RAM (aligned to 1024 byte) */
.ram_vectors (NOLOAD) : {
. = ALIGN(1024);
__ram_vectors_start = .;
* (.ram_vectors);
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_vectors_end = .;
} > SRAM_combined
__ram_vectors_size = __ram_vectors_end - __ram_vectors_start;
/* functions with __attribute__((section(".ram_code"))) */
.ram_code :
{
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_code_start = .;
<snip>Code:
<snip>
__copy_table_start__:
.long __data_load, __data_start, __data_size
.long __ram_code_load, __ram_code_start, __ram_code_size
.long __Vectors, __ram_vectors_start, __ram_vectors_size
__copy_table_end__:
<snip>In startup_XMC4800.s:
Code:
<snip>
/* relocate vectors to RAM */
ldr r0, =SYSTEM_relocateVectorsToRam
blx r0
ldr r0, =main
blx r0
<snip>Code:
<snip>
__attribute__((section(".ram_vectors")))
uint8_t SYSTEM_ramVectors[512]; /** Place holder for vector table in RAM. Will be placed in correct segment by linker,
filled by reset vector and activated by SYSTEM_relocateVectorsToRam() */
/**
* Relocate vectors to RAM.
*
* Must be called after assembler start-up script performed the copy operation from flash.
*/
void
SYSTEM_relocateVectorsToRam(void) {
/* relocate vector table to RAM */
__disable_irq();
SCB->VTOR = (uint32_t) &SYSTEM_ramVectors;
__DSB();
__enable_irq();
}
<snip>↧
↧
SDMMC app upgrade issues (4.0.22 -> 4.3.22
Hi,
The code you mentioned should not be generated for XMC1 family.
It is a bug in the SDMMC_BLOCK APP v.4.0.24.
Use the attached fixed version. To install it:
1. Download and unzip the update site.
2. Use menu Help>Install DAVE APP/Example/Device Libray...
3. Click on Add.. and then in Local button
4. Browse to the folder where you unzip the update site. Select the folder containing the update site. Click Ok
Attachment 3672
5. Select the SDMMC_BLOCK APP. Click Next
Attachment 3673
6. Step through the rest of the dialogs, and after a restart the new version of the SDMMC_BLOCK will be available.
7. You should be able to upgrade your project. Select to upgrade including beta versions
Attachment 3674
Hope this helps until the release of new version of the APP.
Otherwise, are you using the LED/write protection? If not please deselect them. It will also fix the issue.
Regards,
Jesus
The code you mentioned should not be generated for XMC1 family.
It is a bug in the SDMMC_BLOCK APP v.4.0.24.
Use the attached fixed version. To install it:
1. Download and unzip the update site.
2. Use menu Help>Install DAVE APP/Example/Device Libray...
3. Click on Add.. and then in Local button
4. Browse to the folder where you unzip the update site. Select the folder containing the update site. Click Ok
Attachment 3672
5. Select the SDMMC_BLOCK APP. Click Next
Attachment 3673
6. Step through the rest of the dialogs, and after a restart the new version of the SDMMC_BLOCK will be available.
7. You should be able to upgrade your project. Select to upgrade including beta versions
Attachment 3674
Hope this helps until the release of new version of the APP.
Otherwise, are you using the LED/write protection? If not please deselect them. It will also fix the issue.
Regards,
Jesus
↧
How to realize data saving into FLASH while power supply drops?
I'm using XMC4800, and the code is as follow:
What I want is the value of E_EEPROM_XMC4_FLASH_BANK0_BASE increases by 1 when I shut down the power supply.
I wonder whether I'm doing it in the right way, cause it doesn't work.
Code:
#define E_EEPROM_XMC4_FLASH_BANK0_BASE (0x0c01c000U)
uint32_t temp_count[] = {0};
void XMC_FLASH_Program(uint32_t *address, const uint32_t *data, uint8_t length)
{
uint32_t idx;
for (idx = 0U; idx < length; idx += 2U)
{
XMC_FLASH_lLoadPageCommand(data[idx], data[idx + 1U]);
}
XMC_FLASH_lWritePageCommand(address);
while ((FLASH0->FSR & (uint32_t)FLASH_FSR_PBUSY_Msk) != 0U){}
}
void NMI_Handler(void)
{
XMC_SCU_TRAP_Disable(XMC_SCU_TRAP_BROWNOUT);
temp_count[0]++;
XMC_FLASH_Program(E_EEPROM_XMC4_FLASH_BANK0_BASE, temp_count, 1);
__BKPT();
}
int main(void)
{
DAVE_STATUS_t status;
status = DAVE_Init(); /* Initialization of DAVE APPs */
if(status != DAVE_STATUS_SUCCESS)
{
/* Placeholder for error handler code. The while loop below can be replaced with an user error handler. */
XMC_DEBUG("DAVE APPs initialization failed\n");
while(1U)
{
}
}
temp_count[0] = *( __IO uint32_t*)E_EEPROM_XMC4_FLASH_BANK0_BASE;
XMC_FLASH_EraseSector(E_EEPROM_XMC4_FLASH_BANK0_BASE);
XMC_SCU_TRAP_Enable(XMC_SCU_TRAP_BROWNOUT);
XMC_SCU_POWER_EnableMonitor(145, 1);
while(1U)
{
}
}I wonder whether I'm doing it in the right way, cause it doesn't work.
↧
AUIR3200STR Reverse battry polarity Heating Issue
In Normal condition (correct battery polarity) all four MOSFETs are driven by driver, but In case of Reverse battery Polarity (KL30 & KL31 interchanged) as per data sheet of AUIR3200S all MOSFETS should turn ON by driver.
Test condition :
-14VDC battery voltage
While testing above Reverse battery polarity scenario AUIR3200STR Found very HOT. If we test more then 5 sec, driver may blow off.
Seeking your support to solve above issue.
Test condition :
-14VDC battery voltage
While testing above Reverse battery polarity scenario AUIR3200STR Found very HOT. If we test more then 5 sec, driver may blow off.
Seeking your support to solve above issue.
↧
XMC4800: Vector table remap/relocation from flash to RAM (bootloader)
To answer my own question ...
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
In startup assembler file (reset handler), an entry has been added to the copy table to make the start-up script copy vector table from flash to new location in RAM.
In same file the relocate-to-RAM method is called just before main() is called. The relocation could possible be performed in SystemCoreSetup(), but this method is called right at the beginning of the reset handler, where the RAM content has not been loaded and therefore the new RAM vector table is not populated. So I decided to add the new method SYSTEM_relocateVectorsToRam().
In startup_XMC4800.s:
In system_XMC4800.c:
Improvements are welcome, like not hard-coding the size of SYSTEM_ramVectors[].
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
Code:
<snip>
Stack (NOLOAD) :
{
__stack_start = .;
. = . + stack_size;
__stack_end = .;
__initial_sp = .;
} > SRAM_combined
/* vector table in RAM (aligned to 1024 byte) */
.ram_vectors (NOLOAD) : {
. = ALIGN(1024);
__ram_vectors_start = .;
* (.ram_vectors);
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_vectors_end = .;
} > SRAM_combined
__ram_vectors_size = __ram_vectors_end - __ram_vectors_start;
/* functions with __attribute__((section(".ram_code"))) */
.ram_code :
{
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_code_start = .;
<snip>Code:
<snip>
__copy_table_start__:
.long __data_load, __data_start, __data_size
.long __ram_code_load, __ram_code_start, __ram_code_size
.long __Vectors, __ram_vectors_start, __ram_vectors_size
__copy_table_end__:
<snip>In startup_XMC4800.s:
Code:
<snip>
/* relocate vectors to RAM */
ldr r0, =SYSTEM_relocateVectorsToRam
blx r0
ldr r0, =main
blx r0
<snip>Code:
<snip>
__attribute__((section(".ram_vectors")))
uint8_t SYSTEM_ramVectors[512]; /** Place holder for vector table in RAM. Will be placed in correct segment by linker,
filled by reset vector and activated by SYSTEM_relocateVectorsToRam() */
/**
* Relocate vectors to RAM.
*
* Must be called after assembler start-up script performed the copy operation from flash.
*/
void
SYSTEM_relocateVectorsToRam(void) {
/* relocate vector table to RAM */
__disable_irq();
SCB->VTOR = (uint32_t) &SYSTEM_ramVectors;
__DSB();
__enable_irq();
}
<snip>↧
↧
SDMMC app upgrade issues (4.0.22 -> 4.3.22
Thanks for that Jesus, I have removed the LED signal and it works perfectly. I might need to reinable it at some point in the future but by then a new version of the app will be released. I couldn't actually see your attached version of the APP. Thanks,
Nick
Nick
↧
XMC4800: Vector table remap/relocation from flash to RAM (bootloader)
To answer my own question ...
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
In startup assembler file (reset handler), an entry has been added to the copy table to make the start-up script copy vector table from flash to new location in RAM.
In same file the relocate-to-RAM method is called just before main() is called. The relocation could possible be performed in SystemCoreSetup(), but this method is called right at the beginning of the reset handler, where the RAM content has not been loaded and therefore the new RAM vector table is not populated. So I decided to add the new method SYSTEM_relocateVectorsToRam().
In startup_XMC4800.s:
In system_XMC4800.c:
Improvements are welcome, like not hard-coding the size of SYSTEM_ramVectors[].
1. SCB->VTOR needs to be updated. See SystemCoreSetup(). PPB->VTOR will be updated automatically.
2. Created a linker segment, which is placed between stack and .ram_code. The segment must be aligned to 1024 byte in RAM, otherwise relocation will fail (probably?).
Code:
<snip>
Stack (NOLOAD) :
{
__stack_start = .;
. = . + stack_size;
__stack_end = .;
__initial_sp = .;
} > SRAM_combined
/* vector table in RAM (aligned to 1024 byte) */
.ram_vectors (NOLOAD) : {
. = ALIGN(1024);
__ram_vectors_start = .;
* (.ram_vectors);
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_vectors_end = .;
} > SRAM_combined
__ram_vectors_size = __ram_vectors_end - __ram_vectors_start;
/* functions with __attribute__((section(".ram_code"))) */
.ram_code :
{
. = ALIGN(4); /* section size must be multiply of 4 */
__ram_code_start = .;
<snip>Code:
<snip>
__copy_table_start__:
.long __data_load, __data_start, __data_size
.long __ram_code_load, __ram_code_start, __ram_code_size
.long __Vectors, __ram_vectors_start, __ram_vectors_size
__copy_table_end__:
<snip>In startup_XMC4800.s:
Code:
<snip>
/* relocate vectors to RAM */
ldr r0, =SYSTEM_relocateVectorsToRam
blx r0
ldr r0, =main
blx r0
<snip>Code:
<snip>
__attribute__((section(".ram_vectors")))
uint8_t SYSTEM_ramVectors[512]; /** Place holder for vector table in RAM. Will be placed in correct segment by linker,
filled by reset vector and activated by SYSTEM_relocateVectorsToRam() */
/**
* Relocate vectors to RAM.
*
* Must be called after assembler start-up script performed the copy operation from flash.
*/
void
SYSTEM_relocateVectorsToRam(void) {
/* relocate vector table to RAM */
__disable_irq();
SCB->VTOR = (uint32_t) &SYSTEM_ramVectors;
__DSB();
__enable_irq();
}
<snip>↧
SDMMC app upgrade issues (4.0.22 -> 4.3.22
Thanks for that Jesus, I have removed the LED signal and it works perfectly. I might need to reinable it at some point in the future but by then a new version of the app will be released. I couldn't actually see your attached version of the APP. Thanks,
Nick
Nick
↧
Missing Git in Dave V4.4.2
Installing plugins via Eclipse update site does not work:
Attachment 3677
I also have a possibly related problem:
The repository at http://vrapper.sourceforge.net/update-site/stable is not even recognized as an Eclipse update site.
In vanilla Eclipse both plugins can be installed without errors.
While we are at it: Where is the Eclipse Marketplace?
Kind regards
Sebastian
Attachment 3677
I also have a possibly related problem:
The repository at http://vrapper.sourceforge.net/update-site/stable is not even recognized as an Eclipse update site.
In vanilla Eclipse both plugins can be installed without errors.
While we are at it: Where is the Eclipse Marketplace?
Kind regards
Sebastian
↧
↧
2EDL05N06PF HO is no output.
Hello everyone.
I am developing a bdc motor driver circuit.
I chosse 2EDL05N06PF parts.
Now i have a trouble,when use Signal generator test HO is normal,but use mcu pwm test HO is no output.
The details are as follows.
How can i to do next step? Thank you!
Attachment 3678
Attachment 3679
Attachment 3680
I am developing a bdc motor driver circuit.
I chosse 2EDL05N06PF parts.
Now i have a trouble,when use Signal generator test HO is normal,but use mcu pwm test HO is no output.
The details are as follows.
How can i to do next step? Thank you!
Attachment 3678
Attachment 3679
Attachment 3680
↧
XMC4x00: UART TX FIFO example is conceptional wrong
I was using the UART example to send 64 bytes by direct method (polling) and by FIFO. I wondered why it took the same time to send them (149413 vs. 149368 cycles @ 144 MHz on XMC4800), although the FIFO should be much faster (using a FIFO buffer of 64 elements). The send method basically performs:
The 1st (FIFO flush) and the last (FIFO empty wait) code lines nullify the optimization of a FIFO. Why would you actively wait until the FIFO has transfered all of its data? And if you do so, why would you flush FIFO contents before the next transfer starts, because there cannot be any data in FIFO on start of the method UART_lStartTransmitPolling(). Using it that way, it makes no difference whether to use the FIFO or not. Better:
Best regards,
Ernie T.
Code:
void
UART_lStartTransmitPolling(
uint8_t * data_ptr,
uint32_t count) {
/* flush FIFO contents */
XMC_UART0_CH0->TRBSCR = USIC_CH_TRBSCR_FLUSHTB_Msk;
do {
/* wait for TX FIFO to become partially empty */
while (XMC_UART0_CH0->TRBSR & (1<<USIC_CH_TRBSR_TFULL_Pos)) {
}
/* put next byte into FIFO */
XMC_UART0_CH0->IN[0] = *data_ptr++;
} while (--count);
/* wait for FIFO to become empty (= wait for full data sent) */
while (!(XMC_UART0_CH0->TRBSR & USIC_CH_TRBSR_TEMPTY_Msk)) {
}
}Code:
void
UART_lStartTransmitPolling(
uint8_t * data_ptr,
uint32_t count) {
do {
/* wait for TX FIFO to become partially empty */
while (XMC_UART0_CH0->TRBSR & (1<<USIC_CH_TRBSR_TFULL_Pos)) {
}
/* put next byte into FIFO */
XMC_UART0_CH0->IN[0] = *data_ptr++;
} while (--count);
}Ernie T.
↧
xmc4800 Brown-out detection
↧